Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [Bug] Linked worktree sandbox auto-allow missing main .git directory and denyWithinAllow paths off-by-one

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

error: cannot open '<repo>/.git/worktrees/<name>/FETCH_HEAD': Operation not permitted So the worktree exception is partially implemented: the deny list is constructed but mis-pathed, and the corresponding allow entry is absent entirely. Looks like the code that computes the .git directory uses the repo root instead.

Fix Action

Fix / Workaround

Workaround in use: sandbox.excludedCommands: ["git *", "gh *"] plus matching Bash(...) allow rules. Works, but trades the sandbox boundary for git/gh.

Code Example

[]
RAW_BUFFERClick to expand / collapse

Bug Description Regression in 2.1.149/2.1.150: linked-worktree sandbox auto-allow does not cover the main .git directory; denyWithinAllow paths are off-by-one.

Claude Code version: 2.1.150 Platform: macOS Darwin 25.5.0 (Seatbelt sandbox)

Expected (per sandboxing docs § Filesystem isolation > Git worktrees and changelog entry for 2.1.149): when cwd is a linked git worktree, the sandbox auto-allows writes to the main repo's shared .git directory, with hooks/ and config denied.

Actual: in a session created by EnterWorktree (working dir at <repo>/.claude/worktrees/<name>/), git fetch fails with:

error: cannot open '<repo>/.git/worktrees/<name>/FETCH_HEAD': Operation not permitted

Inspecting the resolved sandbox config in the session's system prompt:

  • filesystem.write.allowOnly does not contain <repo>/.git — only ., $TMPDIR, caches, etc.
  • filesystem.write.denyWithinAllow contains <repo>/HEAD, <repo>/objects, <repo>/refs (missing the .git/ prefix; should be <repo>/.git/hooks and <repo>/.git/config per the 2.1.149 changelog).

So the worktree exception is partially implemented: the deny list is constructed but mis-pathed, and the corresponding allow entry is absent entirely. Looks like the code that computes the .git directory uses the repo root instead.

Reproduction:

  1. macOS, Claude Code 2.1.150, sandbox.enabled: true
  2. In any git repo: ask Claude to "work in a worktree" (or run claude --worktree test)
  3. Inside the worktree, run any git fetch or gh pr checkout <n>
  4. EPERM on <repo>/.git/worktrees/<name>/FETCH_HEAD

Workaround in use: sandbox.excludedCommands: ["git *", "gh *"] plus matching Bash(...) allow rules. Works, but trades the sandbox boundary for git/gh.

Confirmed: no Claude-specific xattrs exist on worktree dirs or the parent .git (only com.apple.provenance from macOS), so detection cannot be keyed off xattrs. Issue persists on a freshly created worktree.

Environment Info

  • Platform: darwin
  • Terminal: xterm-256color
  • Version: 2.1.150
  • Feedback ID: 6af9b50a-5f3b-40c7-946a-54e67dcb7946

Errors

[]

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING