claude-code - 💡(How to fix) Fix Worktree subagents branch from `origin/main` rather than current HEAD — intentional? [1 comments, 2 participants]

Question

When Claude Code dispatches a subagent with isolation: "worktree", the new worktree branch is created from origin/main rather than the branch currently checked out in the launching session. I want to confirm whether this is intentional and, if so, request either documentation or a configuration knob — because the observable effect on repos with local-only branches is subagents operating on arbitrarily stale code without any visible signal.

Related to #36182 but mechanically distinct. That thread focuses on tool-level path resolution (Edit/Write/Bash leaking to main-repo absolute paths). This is one layer upstream: the worktree's base commit selection at creation time. Fixing this alone would not fix #36182, but the two may share a root cause in how CC resolves "the canonical repo state."

Environment

• Claude Code v2.1.112
• Platform: Linux 6.6.87.2-microsoft-standard-WSL2 (Ubuntu on WSL2)
• Model: claude-opus-4-7

Observation

Repo state at the time of dispatch:

$ git branch --show-current
dev
$ git rev-parse dev
54e6e3849ea62cdbbe4e17f3ab0478fb36a2576e            # current checked-out HEAD
$ git rev-parse origin/main
39c63e8465b8d9b3c9cefeca231b2151535ba009            # 16 days old, 426 commits behind dev
$ git rev-list origin/main..dev --count
426                                                  # local-only work, no origin/dev exists

Dispatch a no-op subagent:

Agent({
  subagent_type: "general-purpose",
  isolation: "worktree",
  description: "no-op probe",
  prompt: "Run: pwd"
})

The new worktree is rooted at 39c63e8 (origin/main), not 54e6e38 (dev HEAD):

$ git worktree list
/home/dhx/repos/forgefinder                                   54e6e38  [dev]
/home/dhx/repos/forgefinder/.claude/worktrees/agent-<id>      39c63e8  [worktree-agent-<id>]  locked

The worktree's own reflog is explicit about this:

$ git reflog worktree-agent-<id>
39c63e8 worktree-agent-<id>@{...}: branch: Created from origin/main

And CC's internal CLAUDE_BASE file records the choice:

$ cat .git/worktrees/agent-<id>/CLAUDE_BASE
39c63e8465b8d9b3c9cefeca231b2151535ba009

Reproducible on every dispatch — four consecutive no-op probes produced four worktrees all rooted at 39c63e8.

Impact

• Subagents see stale code. On this repo, the subagent's working tree is 16 days and 426 commits behind what the outer session sees. Files added on dev in those 426 commits don't exist in the worktree; files modified look like their pre-change versions. A subagent asked to "extend the migration probe" in a file that was added on dev would fail to find it via Glob/Read.
• Silent. No warning surfaced. The outer session has no indication the subagent's view differs from its own.
• Affects a common configuration: any repo with local-only feature branches, unpushed WIP, forks where origin/main is upstream-default but not user-current, or simply repos where origin/main has fallen behind the working branch. Not a niche edge case.
• Plausibly amplifies #36182. Thread observations there report the worktree branch "stays untouched at its original commit" (@0l0v3r1) and that some paths resolve correctly while others leak to main (@mikehenson, my prior comment). A worktree whose file tree doesn't match what the subagent expects is exactly the condition under which the agent would cache main-repo-resolved paths from its launching context rather than relying on the worktree's own tree. Fixing base selection alone wouldn't fix the tool-resolver bug — but it would narrow the divergence the resolver has to bridge.

What I'm asking

1. Is origin/main as the worktree base intentional? (E.g. chosen as a "known-stable" reference that's immune to in-session branch moves.)
2. If yes — can this be documented? The CC docs I've found don't mention it, and the behavior isn't what a user observing git worktree list would infer from their current checkout.
3. If yes — can it be configurable? A setting or repo-level hook to opt into "use current HEAD" or "use `<configured branch>`" would cover the affected configurations without changing the default.
4. If no — then the fix direction is probably to take the launching session's `git rev-parse HEAD` (or its symbolic-ref) as the base, with `origin/main` as fallback only when the working tree is detached or the ref can't be resolved.

Happy to provide additional forensic detail (full git worktree list, reflogs, CC session metadata, hook-stack artifacts) if useful.