feat(settings): new worktrees can start from a configured base branch#29506

🟠 High threads/new-task-flow-provider.tsx:657

Switching a restored local draft to worktree mode before server config loads permanently pins the checkout branch (for example, feature) instead of applying the configured base (for example, dev). With config unresolved, newWorktreesBaseBranch is "", so resolveWorktreeSwitchBranch returns selectedBranchName; persisting it prevents fillNewTaskWorkspaceBranch from filling the configured base later. Keep the branch unset until selectedEnvironmentServerConfig is available.

Fixed in 86c8f01a03. Until the environment's server config loads, the switch now passes an unknown base, so resolveWorktreeSwitchBranch leaves the branch unset and fillNewTaskWorkspaceBranch fills the configured base once settings arrive. One trade-off: with no base configured, a switch made in that window shows the repository default rather than the checked-out branch.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

External image Major · Functional Correctness · Quick win

Require a successful ref load before assigning the base branch.

If the first ref request fails while the status request succeeds, isInitialBranchesLoadPending becomes false with branchRefState.data === null. The resolver then ignores a configured base such as dev and assigns currentGitBranch. Once the effect stores that branch, a later ref refresh cannot correct it because activeThreadBranch is no longer empty. Keep the candidate unavailable until the initial ref response succeeds. (raw.githubusercontent.com)

✅ Confirmed as addressed by @AyushKaithwas

Fixed in cb80403f20. When the first ref load fails, repo capability now comes from the git status query, so a configured base still wins over the current branch.

@AyushKaithwas Thanks. The supplied code now falls back to branchStatusQuery.data?.isRepo when ref data is unavailable. If status confirms a repository, the configured base remains preferred over currentGitBranch. This addresses the reported failure case without requiring a successful ref load.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Keep the configured base derived until the user chooses a branch.

If a user re-selects New worktree, this line saves the resolved configured base as workspaceSelection.branch. setStartFromOrigin does the same at Line 698 when the user toggles Start from remote. After either action, changing the configured base leaves the draft pinned to the old branch, so submission can create the worktree from the wrong base. Preserve the draft’s explicit branch, if any, instead of saving selectedBranchName in these paths.

✅ Confirmed as addressed by @AyushKaithwas

Fixed in cb80403f20. In worktree mode, re-selecting New worktree and toggling Start from remote now write the draft's explicit branch (null when it was only filled), so the base stays derived and a later setting change applies.

@AyushKaithwas The supplied code confirms both paths now preserve explicitDraftBranch. A derived base remains null in the draft, so later setting changes can apply without replacing an explicit branch choice. This addresses the finding.

📝 Learnings were not changed: only organization members or users with write access to this repository can add or remove learnings.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Major · Functional Correctness · Heavy lift

Wait for server settings before deciding whether to reset.

useEnvironmentSettings returns default settings while the server settings are unavailable. If a restored local draft has a branch and the user selects New worktree before settings load, this check sees an empty base and keeps the old branch. The branch selector will not replace that branch when the configured base arrives. Defer the decision or retain the transition until settings load. (raw.githubusercontent.com)

✅ Confirmed as addressed by @AyushKaithwas

Fixed in cb80403f20. Until the environment's server settings load, the base is treated as unknown and the branch is cleared on the switch, so the selector fills the configured base once settings arrive. With no base configured, a switch in that window shows the repository default rather than the checked-out branch, the same as mobile.

@AyushKaithwas Verified the fix by code inspection. Before settings load, worktreeBaseBranch is null, so switching from local to worktree mode clears the branch. The selector waits for settings before choosing the base. This addresses the reported race.

The helper test covers the unknown-settings case. I did not run tests.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Major · Functional Correctness · Heavy lift

Wait for settings before resolving the worktree base.

When refs arrive before server settings, this stores a null branch, but resolveNewTaskDraftWorkspace treats the selected mode as settled and immediately fills the repository default. With a saved model, the user can submit or queue that branch before a configured base such as dev loads. Pass settings readiness through the resolver and keep the branch unresolved until settings load. (raw.githubusercontent.com)

Not changing this. On mobile, server config arrives with the transport session (initialConfigValueAtom), and refs are fetched over that same session, so online the config is present before refs. The only case with refs and no config is offline, where the cached refs fill the repository default on purpose (uses cached repository capability and branch defaults while offline in new-task-flow-provider.test.tsx). Waiting for settings there would leave offline worktree drafts with no base. I tried it, and that test fails.

@AyushKaithwas You're right. My finding assumed that online refs could arrive before server config. The transport-session ordering you described rules out that scenario.

The offline fallback is intentional. Waiting for server config would prevent cached refs from supplying the repository-default base, contrary to the test you cited.

I withdraw this finding. No change is needed for this comment.

Review thread resolved.

_{You are interacting with an AI system.}

External image Major · Functional Correctness · Heavy lift

Preserve the checkout branch until settings load.

If the user switches from checkout branch release while settings load, this returns null. If the loaded setting is empty, the later resolver selects the repository default, such as main, rather than release. Switching after settings load retains release. Preserve the checkout branch until the setting is known, and use it when the setting is empty. (raw.githubusercontent.com)

Keeping this as is. For the reason in the sibling thread, config is only missing while offline. There the configured base is unknown. Leaving the branch unset means the draft picks up the configured base once the app reconnects, while pinning the checkout's branch would keep it off the configured base for good. The cost is that offline, with no base configured, the switch shows the repository default instead of the checked-out branch. That's the trade-off noted in the earlier reply.

@AyushKaithwas Understood. I withdraw this finding.

fillNewTaskWorkspaceBranch preserves any non-null branch, so retaining the checkout branch would prevent the configured base from taking effect after reconnecting. Leaving the branch unset preserves that behavior. The offline fallback to the repository default is an accepted trade-off, not a defect that requires this change.

📝 Learnings were not changed: only organization members or users with write access to this repository can add or remove learnings.

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Data Integrity & Integration · Quick win

Migrate legacy derived worktree branches.

This treats every stored workspaceSelection.branch as an explicit user choice. The previous implementation persisted selectedBranchName when switching modes or toggling remote, even without an explicit branch selection. Draft persistence still uses schema version 1 and has no explicitness marker or migration. Such drafts keep the old branch because non-null branches bypass base resolution. Add explicit-branch metadata with a migration, or clear legacy derived branches. (raw.githubusercontent.com)

Not changing this. A draft saved before this PR stored the branch main would also use, so it only diverges if someone configures a base while that old draft is still open. Picking a branch or starting a new draft fixes it. A draft schema migration with explicitness metadata is out of scope for this setting.

@maria-rcks Understood. Existing drafts can keep their stored branch. Selecting the desired branch or starting a new draft provides a workaround.

Would you like a follow-up issue for legacy draft migration?

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Preserve the checkout branch when the resolved base is empty.

A local draft that selects New worktree before settings load loses its checkout branch because useComposerSelection passes null, and shouldResetBranchForNewWorktree treats null as a reset condition. When the setting later resolves to empty, the selector fills the repository default instead of the checkout branch.

Do not only skip the reset while settings load. The selector currently returns when activeThreadBranch is set, so that change would prevent a later configured base such as dev from replacing the checkout branch. Coordinate the transition and selector effect so an empty resolved base preserves the checkout branch, while a configured base replaces it after settings load.

Not changing this. It's the same trade-off as the mobile thread: only a switch made before server settings load with no base configured shows the repository default instead of the checkout branch. Keeping the checkout branch there would block a configured base from applying, because the selector never replaces a set branch. Fixing both needs explicit-branch tracking, which would grow this PR.

@maria-rcks Understood. The current behavior favors applying a configured base when settings load. I won’t ask for a change in this PR.

Would you like me to open a follow-up issue for the empty-base case?

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Keep the repository default independent of picker search.

If refs load before settings, a user can search the branch picker while settings are pending. The search changes the ref list used to derive defaultBranchName. When the setting is Repository default and the search excludes the default ref, this effect assigns currentGitBranch instead. Clearing the search cannot correct the assignment because activeThreadBranch is then nonempty. Resolve the default from an unfiltered ref result, or keep the picker unavailable until settings load. (raw.githubusercontent.com)

Not changing this here. defaultBranchName comes from the search-filtered refs on main too, so the search dependence predates this PR. The PR only adds the "refs loaded, settings still pending" window, and on web the server settings arrive with the connection before refs. Resolving the default from an unfiltered query would be a separate change.

@maria-rcks Understood. The search-dependent lookup predates this PR, and you’ve chosen to address it separately. I have not verified the settings and refs arrival order.

Would you like me to open a follow-up issue for the search-dependent default lookup?

_{You are interacting with an AI system.}