[BUG] Agent isolation:"worktree" locks Bash/Edit to the wrong repo when the sub-agent's task is in a different repo

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 3, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

What's Wrong?
When I dispatch a sub-agent with isolation: "worktree", it creates a git worktree of the repo my main session is running in — not the repo the sub-agent's task actually needs. If the sub-agent's work is in a different repo (I have several separate git repos side by side in one folder), its Bash and Edit tools get locked to that wrong worktree path and refuse any git command or file edit against the real target repo. There's no clear error explaining why — it just fails.

This has happened 3 separate times across different sessions. Each time, the sub-agent discovered on its own that the PowerShell tool isn't restricted the same way, and used it instead to get the work done. That's a workaround, not a fix, and it shouldn't be necessary.

Similar, but different:

  • #69943 — "Subagents should inherit their worktree's cwd + permission scope across tool calls (instead of resetting to the main repo dir)" — closest structural match, but framed as resetting to "the main repo dir" rather than specifically a different sibling repo entirely.
  • #76197 — "Agent isolation:'worktree' cwd pin drifts back to main repo mid-run — git-mutating commands land in wrong repo" — related symptom (wrong repo), different mechanism (drift mid-run vs. pinned wrong from the start).
  • #75430 — "isolation: worktree forks new agent trees relative to the primary checkout's live state, not the calling session's own tree" — same general area (isolation resolves against the wrong base), different specific claim.
  • #74071 — commands landing in the parent worktree instead of the isolated one — adjacent but about concurrency timing, not repo choice.

What Should Happen?

Expected: isolation: "worktree" should isolate whichever repo the sub-agent's task actually operates in — or at minimum, give a clear error explaining that isolation only applies to the current repo, instead of silently refusing operations against anywhere else.

Error Messages/Logs

Actual: it isolates the caller's own repo regardless of where the task points, with no clear signal about why the target repo's operations are being blocked.

Steps to Reproduce

Steps to reproduce:

  1. Have a working directory containing multiple separate git repos (e.g. Development/repo-a, Development/repo-b).
  2. Start a session with repo-a as the working directory.
  3. Dispatch a sub-agent (Agent tool) with isolation: "worktree", whose task is entirely inside repo-b.
  4. The sub-agent's Bash and Edit tools refuse git/file operations against repo-b, because they're pinned to a worktree created for repo-a instead.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code).

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗