[Feature]: Choose the default base for new worktrees, including the current branch

[guryanov-a]

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 (new-thread composer, worktree base branch picker) and server settings

Problem or use case

When the default workspace is New worktree, a new thread's worktree starts from the repository default branch (origin/HEAD). There is no setting to change that, so the base has to be picked by hand in the "From " chip on every new thread.

This hurts most when work is temporarily focused on a long-lived branch that is not the default. Example: the project checkout is on final-optimizations and every new thread for the next few days should branch from it, but each new thread shows From develop. If you forget to change the chip, the thread's worktree starts from the wrong base, and you usually notice only after the agent has done some work.

A fixed per-project branch name helps teams whose base never changes (dev instead of main). It does not help this case, because the branch you are focused on changes every few days or weeks, and the setting would need editing each time.

Proposed solution

Make the default base for new worktrees a setting with a few modes, following the same environment → project inheritance as Start from remote:

1. Repository default branch: today's behavior, and the default value.
2. Current branch of the project checkout: the branch checked out in the project root when the thread is drafted. Detached HEAD or an unborn branch falls back to the repository default (see fix(web): don't seed the worktree base from an unborn HEAD #25721).
3. Configured branch: a fixed branch, tag, or commit, as in feat(settings): choose the branch new worktrees start from #22750 and feat(settings): new worktrees can start from a configured base branch #25942.

In every mode, an explicit pick in the branch chip still wins, and Start from remote still applies (final-optimizations → origin/final-optimizations when it exists on the remote).

The current-branch mode does not need to be the default. It should just be one of the options.

Why this matters

The current branch is already used as a base elsewhere: worktrees created through the worktree MCP tools without a baseRef start from the project's checked-out branch (noted as unchanged in #22750 and #25942). The composer is the only entry point where it is not available, so a thread started by hand and a thread an agent hands off from the same checkout get different bases.

Smallest useful scope

If #22750 or #25942 lands, the current-branch mode could be added to it as a special value or a mode selector next to the branch field, instead of a separate setting. The resolution order would become: explicit pick → mode (configured branch / current branch / repository default) → existing fallbacks.

Alternatives considered

• Configured branch only (feat(settings): choose the branch new worktrees start from #22750, feat(settings): new worktrees can start from a configured base branch #25942). Solves the "team always branches from dev" case, but the value has to be kept in sync by hand whenever the focus branch changes.
• Default workspace = Current checkout. Threads then run on the current branch, but you lose worktree isolation and parallel threads share one checkout.
• Changing origin/HEAD locally. Also changes which branch T3 Code treats as the default for pull requests and diffs (as noted in feat(settings): choose the branch new worktrees start from #22750).

Risks or tradeoffs

• With the current-branch mode, the base depends on checkout state that can change between drafting and sending. The chip already shows the resolved base before sending, so this stays visible.
• Scheduled tasks that launch fresh threads have their own base branch handling ([Bug]: Scheduled tasks that launch a fresh thread always branch from main and fail every run in repos without it #16183). Whether they should respect this setting needs a decision.

Examples or references

• feat(settings): choose the branch new worktrees start from #22750: feat(settings): choose the branch new worktrees start from (open)
• feat(settings): new worktrees can start from a configured base branch #25942: feat(settings): new worktrees can start from a configured base branch (open)
• feat(settings): per-project default base branch for new worktrees #17472: per-project default base branch for new worktrees (closed during PR cleanup, not rejected on merit)
• [Bug]: Scheduled tasks that launch a fresh thread always branch from main and fail every run in repos without it #16183: scheduled tasks that launch a fresh thread always branch from main
• fix(web): don't seed the worktree base from an unborn HEAD #25721: don't seed the worktree base from an unborn HEAD
• Seen on T3 Code 0.1.5, macOS

Contribution

• I would be open to helping implement this.

[guryanov-a]

Duplicate of #6866, which already lists the current-branch option. I added my use case there: #6866