One session's HEAD silently changes when another session in the same repo creates/modifies a worktree

Summary

When two Claude Code sessions are open on the same git repository (one in the root checkout, one in a .claude/worktrees/<name> worktree), actions taken by Session A silently change Session B's working state. Specifically: Session B's HEAD branch is moved without Session B doing anything, and uncommitted files appear in Session B's working tree.

This violates the principle that each session's worktree should be isolated. The root checkout should not be dragged along by side actions in adjacent worktrees.

Symptoms observed in one work day

All three of these happened in a single multi-hour session today, with one or more other Claude Code sessions running against the same repo:

1. HEAD silently moves between branches. Mid-conversation, my session went from main to docs/screenshot-refresh (a branch I had never created, switched to, or interacted with) with uncommitted screenshot work appearing on disk. I had not run git switch, git checkout, or any branch-changing command.

2. My commits land on the wrong branch. Earlier in the same session, I ran git switch -c feature/charger-identification from main, did substantial work, ran git commit. The commit output showed [docs/nav-mobile 61b417d] — my work landed on docs/nav-mobile, a branch I had never typed. Cleanup required a force-push to move the work to the intended branch. The diagnostic [Extra argument 'adapter' in call (SourceKit)] was also generated repeatedly from SourceKit cache that disagreed with the on-disk file state, because the parent process kept its old view.

3. The earlier "Shell cwd was reset" pattern. Documented as the known symptom in #53849 family. In my case it surfaced when another session removed a worktree that my session was inside.

Why it matters

• Wrong-branch commits. Real risk that work lands on a branch the user didn't intend, leading to force-pushes (destructive operations the global guidance specifically warns against) just to recover.
• Phantom git status. I see files I never touched. Triaging them takes turns and creates a risk of accidentally committing alien work into my own commit.
• Stale tooling diagnostics. SourceKit reports phantom errors against a file state the actual build doesn't have, because the editor's view of the working tree differs from what's on disk after the silent switch.
• Recovery is non-obvious. Detecting "I'm not on the branch I think I'm on" requires checking git branch --show-current before every commit — defensible but burdensome and forgettable.

Expected behaviour

A Claude Code session bound to a working directory should:

• Have its HEAD branch be stable for the lifetime of the session, regardless of what other sessions or worktrees do in the same repository.
• Not have other sessions' uncommitted files appear in its git status.
• Be isolated such that another session creating a new worktree or branch in the same repo does not affect this session's git rev-parse HEAD or working tree contents.

If a true filesystem move is unavoidable (e.g. the user manually deleted the directory the session was running in), the failure mode should be loud — refuse to proceed with destructive operations until the user re-anchors the session.

Actual behaviour

The session's HEAD and working tree are mutated by other sessions' git operations. There is no warning, no notification, and git status shows whatever the other session put there as if it were the current session's work.

Reproduction (best guess; I have not yet captured a clean reduction)

1. Open two Claude Code sessions, both pointed at the same git repository.
2. Session A is in the root checkout (no worktree, or .claude/worktrees/<a>).
3. Session B is in .claude/worktrees/<b>.
4. From Session B, create a new worktree or new branch in the repo (e.g. via git worktree add for a different task).
5. Return to Session A. Run git branch --show-current. Observe that Session A's HEAD has moved without Session A doing anything.

I have not isolated whether the root-checkout case is the trigger (since the root checkout's HEAD is the default for any operation that doesn't explicitly target a worktree), or whether the bug fires between two .claude/worktrees/* siblings as well.

Related issues

• #45815 — sessions ignoring CLAUDE.md isolation rules. Different cause: that's about the model not checking context. This bug is about the context changing under the model's feet even when it does check.
• #58384 — worktree isolation default-on causing stale-deploy bugs. Related theme (worktrees and the root checkout interact in surprising ways) but different surface (this is HEAD movement, not stale build artifacts).
• #53849 — "Shell cwd reset" message noise. Same family of symptoms; this report is about the underlying state mutation, not the message.

Suggested fixes (any one would help)

• Pin each session to its worktree. When a session starts, record git rev-parse --show-toplevel and refuse to honor git operations that target outside that toplevel without explicit user permission.
• Detect and warn on silent HEAD movement. Compare the recorded HEAD at session start against the current HEAD before every tool call; if it has changed without the session having issued a branch-changing command, surface a banner: "Your HEAD was moved by another process. Continuing here may not be what you want."
• Refuse to use the root checkout for new sessions. Force every session into a dedicated .claude/worktrees/* worktree at start. The root becomes inert, only used for human reviewer git operations. This isolates the failure surface.

Environment

• Claude Code CLI version: 2.1.140
• macOS: 26.4 (build 25E246)
• git: 2.50.1 (Apple Git-155)
• Multiple concurrent sessions on the same repo via .claude/worktrees/*.

Workaround in use

Defensive git branch --show-current before every commit. Force-push (git push --force-with-lease) to recover when a commit landed on the wrong branch. Neither is a fix.