Agent tool's isolation: "worktree" does not isolate git HEAD modifications — subagent's git checkout affects parent repo's branch

Resolved 💬 3 comments Opened May 3, 2026 by R2calex Closed May 6, 2026

Summary

When dispatching a subagent with isolation: "worktree", the runtime creates a separate git worktree for the agent. However, the agent's shell cwd (or the way git is invoked inside its sandbox) does not appear to be locked to the worktree path. As a result, when the agent runs git switch -c <feat-branch> or git checkout <feat-branch>, the operation modifies the parent repo's HEAD instead of the worktree's HEAD.

Reproduction

  1. Have a clean repo on main. Note main worktree is at /repo.
  2. Dispatch a subagent with isolation: "worktree" and prompt it to create a feature branch and commit work to it.
  3. The runtime creates a worktree at, e.g., /repo/.claude/worktrees/agent-XXXX checked out on a temp branch worktree-agent-XXXX.
  4. Inside the agent's session, the agent runs (paraphrased): git switch -c feat/some-branch.
  5. After the agent returns, run git worktree list from /repo (the parent).

Observed:

$ git worktree list
/repo                                                a130621 [feat/some-branch]      ← parent's HEAD switched!
/repo/.claude/worktrees/agent-XXXX                   a130621 [worktree-agent-XXXX] locked

The parent worktree's HEAD is now feat/some-branch. Any uncommitted changes the user had on main in the parent are now in a confusing state, and the user's interactive shell is on a branch they didn't create.

Expected behavior

The isolation: "worktree" parameter should make any git operation the subagent runs operate on its own worktree. Either:

  • (a) The subagent's shell cwd is locked to the worktree path and git commands resolve to the worktree's HEAD by default; or
  • (b) The subagent's environment exports GIT_DIR/GIT_WORK_TREE pointing at the worktree; or
  • (c) The runtime intercepts subagent git commands and routes them to the worktree (heaviest option).

If none of these is feasible, the documentation must explicitly warn that git commands inside an isolation: "worktree" agent affect the parent repo, and that agents must always pass -C <worktree_path> to git invocations — but that's a footgun the parent (orchestrator) cannot enforce.

Actual behavior

The "isolation" is at the filesystem level (the agent has its own working tree directory) but not at the git-state level (git checkout mutates parent HEAD). This silently corrupts the parent's branch state.

Impact

  • Parent repo's branch can be switched by a subagent the user has no direct view into
  • Multiple parallel subagents can checkout each other's branches into the parent in race conditions
  • Loose work (uncommitted changes) on the parent's working tree gets entangled with whatever branch the subagent switched to
  • The parent has to manually git switch main after subagents return to recover normal state — and discover this state corruption via git worktree list, not through any tool feedback

Environment

  • Claude Code CLI
  • Linux (WSL2)
  • Agent tool with subagent_type: general-purpose, isolation: "worktree"

Suggested fix

Lock the subagent's shell cwd to the worktree path AND/OR set GIT_DIR/GIT_WORK_TREE in the subagent's environment so that bare git commands operate on the worktree by default. If neither, prominently document the footgun on the Agent tool's isolation parameter.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗