Skip to content

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

Closed

Description

@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

Risks or tradeoffs

Examples or references

Contribution

  • I would be open to helping implement this.

Activity

  1. locked and limited conversation to collaborators on Oct 30, 2026
  2. converted this issue into a discussion #27659 on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions