[Feature]: Allow configuring the default base branch for new worktree threads

[MatejSkarka]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

I use T3 Code with New threads → New worktree and Start from origin enabled.

When I create a new thread while viewing an existing thread on a feature branch, the base branch picker inherits that thread's branch, for example:

From agent/month-view-all-day-default

For unrelated tasks, I want each new worktree thread to start from the repository's default branch, usually main. Today I must manually select main for every new thread. This makes it easy to accidentally base an unrelated task on a previous feature branch.

Proposed solution

Add a setting for the default base branch used by new worktree threads.

Suggested options:

• Repository default branch (origin/HEAD, usually main)
• Current branch
• Remember the last selected branch
• A specific branch configured per project

My preferred default is Repository default branch.

This should be independent of the existing settings:

• New threads → New worktree controls where the thread runs.
• Default base branch controls which ref the worktree starts from.
• Start from origin controls whether the latest remote version of that branch is used.

The branch picker should remain available for one-off overrides.

Why this matters

A new thread often represents a new, unrelated task. Inheriting the currently viewed feature branch is useful for follow-up work, but surprising and potentially unsafe for independent work.

A predictable workflow would be:

• New thread starts from the configured default base branch.
• Fork or continue from an existing thread inherits that thread's branch.
• The user can explicitly select another branch when needed.

This would reduce accidental branch dependencies.

Smallest useful scope

Add a global setting with two options:

• Repository default branch
• Current branch

Use it to initialize the base-branch picker for a new worktree draft. A per-project override could be added later.

Alternatives considered

• Manually selecting main works, but is repetitive and easy to forget.
• Keeping the local checkout on main does not fully solve the problem because the picker can inherit the branch of the currently viewed thread.
• Start from origin updates the selected branch from its remote counterpart, but does not choose the branch.

Risks or tradeoffs

Some users intentionally create new threads as follow-ups to the active feature branch. Changing the behavior unconditionally could disrupt that workflow.

Making it configurable preserves both workflows.

Examples or references

Observed on T3 Code Alpha 0.0.31 on macOS.

Current settings:

• New thread mode: New worktree
• Start from origin: Enabled

Related but distinct: #1111 discusses syncing a selected base branch from origin. This request concerns which base branch is selected by default.

Contribution

• I would be open to helping implement this.

[AyushKaithwas]

I'd like to choose a base such as dev per project without changing the repository's GitHub default. #10530 describes the same need.

I opened #13592 with a Worktree base ref setting: repository default, a specific branch/tag/commit, or Last used. Last used remembers explicit selections per project and environment on the current device; that behavior is adapted from #11991 by @Nortus222. Existing drafts and one-off branch choices keep their selection, and Start from origin still applies independently. The PR includes screenshots and validation details for the web and mobile changes.

Would maintainers want this scope, or prefer a smaller version with just a fixed base per project? If the approach fits, the PR's CI is waiting for maintainer approval.

[rutmehta]

+1 — I'd like new worktree threads to always start from the repository default branch (main), regardless of which thread is open. Inheriting the viewed thread's feature branch has based unrelated work on the wrong branch for me.

Note: #13592, the PR implementing this, was closed without merging, so this is still unaddressed.

[AyushKaithwas]

@juliusmarminge #13598 was closed as not planned, but this discussion is still in triage and people keep asking for it (9 upvotes, most recently @rutmehta). Would you accept a smaller version than #16451? I've opened #25942 so you can judge it from the code. It adds one setting for where new worktrees branch from: the repository default, or a branch you pick, like dev, set per project if you want. Leaving it empty keeps today's behavior. That covers both asks here: starting from main instead of the open thread's branch, and projects whose work branches from something other than the GitHub default. No "last used" memory and no global scope. My earlier attempts were #13592 and #16451. Happy to cut it down further or close it if you'd rather go another way.

[guryanov-a]

+1, and I'd like the Current branch option from the list above to survive into whatever lands.

My case is the opposite of the original one: for a few days or weeks, work focuses on a long-lived branch that isn't the default (for example final-optimizations while develop is the default). Every new thread should branch from it, but the composer shows From develop, so I re-pick the base on each thread. A configured branch (#22750, #25942) helps, but it has to be edited each time the focus branch changes. "Current branch of the project checkout" would follow it automatically.

It would also make the composer consistent with agents: worktrees created through the worktree MCP tools without a baseRef already start from the project's checked-out branch (both #22750 and #25942 leave that unchanged).

Suggested modes, with the repository default kept as the default: repository default / current branch of the project checkout / configured branch. An explicit pick in the branch chip still wins, and Start from origin still applies.

(Closing my #27659 as a duplicate of this.)

[AyushKaithwas]

Update: #25942 was closed for missing verification, so I reopened it as #29506 with the evidence, and a maintainer has since verified it in a real dev environment. It adds Settings → Worktrees → Base branch, a branch picker you can set per project. New worktrees start from that branch, and switching a draft from Current checkout to New worktree uses it too. #29505 is a small branch-picker fix it builds on.

@guryanov-a, for your case you could set the project's base to final-optimizations while that work lasts, then switch it back to Repository default.

[guryanov-a]

@guryanov-a, for your case you could set the project's base to final-optimizations while that work lasts, then switch it back to Repository default.

That's rather a workaround, git's current branch (which changes with git checkout branch-name) option would automatically do what you suggest

[chirayuChhabra]

I need this for a workflow where develop is the development branch and main is reserved for production. With New worktree enabled, each new thread defaults to main, so I have to select develop manually every time.

Please allow saving a default worktree base branch globally, with a per-project override. For example, setting a project's base to develop should initialize every new worktree draft from that branch while still allowing a one-off selection in the composer. The existing Start from remote setting should continue to control whether it uses the remote or local version of that branch.

The workspace choice should stay independent: some threads need a new worktree, while others should use the current checkout or reuse an existing worktree. Choosing Current checkout is not a substitute for selecting the default base of a new worktree.

Observed on T3 Code 0.1.8-nightly.20261108.4353 on macOS.