Desktop app's worktree creation ignores the `worktree.baseRef` setting

Desktop app's worktree creation ignores the worktree.baseRef setting

Environment

• Claude for Desktop 1.24012.9 (app.asar built 2026-07-24)
• Claude Code CLI 2.1.220 (~/.local/share/claude/versions/2.1.220)
• macOS 15 (Darwin 25.5.0), arm64

Summary

worktree.baseRef: "head" in ~/.claude/settings.json is honored by the CLI's
EnterWorktree tool, but not by the worktree that the desktop app creates when you
start a new session in a worktree. The desktop app always branches from
origin/<default-branch>, silently discarding the user's setting.

Expected

Per the setting's own schema:

baseRef: enum(["fresh","head"])
  'fresh' (default) branches from origin/<default-branch> for a clean tree.
  'head'  branches from your current local HEAD so unpushed commits and
          feature-branch state are present.

With "head", a worktree created while the repo is on a local feature branch should
branch from that branch.

Actual

The new worktree is branched from origin/main, freshly fetched, with --no-track.
The user's local feature branch state is absent.

Reproduction

1. ~/.claude/settings.json:

``json
{ "worktree": { "baseRef": "head" } }
``

1. In a repo whose default branch is main, check out a long-lived local feature branch

that has commits not on main.

1. From the desktop app, start a new session in a worktree.
2. In the worktree: git log --oneline -1 → it is at origin/main, not the feature branch.

Evidence

The CLI reads the setting (from the EnterWorktree implementation in 2.1.220):

i = r?.fromHead ?? (!r?.prNumber && eo().worktree?.baseRef === "head")

The desktop app has its own createWorktree in app.asar that does not:

u = await this.resolveDefaultSourceBranch(i)   // repo default branch
await this.maybeRefreshOrigin(i)
await this.refreshSourceRef(i, m, e.signal)
// git worktree add -c core.longpaths=true --no-track -b <branch> <path> <startPoint>
// startPoint = resolveWorktreeStartPoint(i, u)
// falls back to readCurrentBranch(i) only if the default branch does not resolve

Enumerating every occurrence of baseRef in app.asar: the only worktree-related one
is the settings schema definition (baseRef: g.enum(["fresh","head"]), shipped for
validation). There is no read of the setting anywhere in the app, and no UI to choose the
source branch. The remaining hits are all PR-related (headRef / baseRef /
baseRefName).

Impact

Silent and easy to miss. Work starts on a base that lacks the feature branch's commits, so
anything that depends on that state fails for reasons that look like a code problem. In our
case a test-fixing task began on a base without the prerequisite commit; the failures looked
like the changes were wrong until we compared the worktree's HEAD against the branch we
thought we were on. There is no warning at session start that the base differs from the
repo's checked-out branch.

Suggested fix

Either honor worktree.baseRef in the desktop app's createWorktree (pass the equivalent
of fromHead through to resolveWorktreeStartPoint), or — if the app intentionally always
wants a clean base — surface the source branch in the new-worktree-session UI and note in
the setting's description that it applies to CLI-created worktrees only. The sourceBranch
plumbing already exists in the app's session config; it just isn't reachable from the UI.