[BUG] Sandboxed Bash tool blocks .git writes (refs/heads, index.lock) despite filesystem.allowWrite/excludedCommands overrides

Status Open
Reported on v2.1.283
Maintainer reply None cached
Activity 0 comments · opened Sep 28, 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?

Environment: sandbox enabled via managed settings (sandbox.enabled: true, failIfUnavailable: true), no sandbox.filesystem.disabled.

Summary: In a repo the current account owns, running git switch -c <branch> and git add <file> fail from Claude Code's Bash tool with Operation not permitted on .git/refs/heads/<branch>.lock and .git/index.lock respectively — even though:

The account has full read/write/execute permissions on every directory in the path (verified with stat/ls -le, no ACLs).
The exact same commands succeed instantly when run in a plain interactive shell as the same account, outside Claude Code entirely.
Per the sandboxing docs, .git under the working directory should already be writable by default ("read and write access to the current working directory and its subdirectories"), and neither refs/heads nor index appear in the documented non-exemptable "protected paths" list (only .git/hooks and .git/config are named there).
Adding sandbox.filesystem.allowWrite: [".git"] to both project (.claude/settings.json) and managed (managed-settings.json) settings had no effect.
Adding sandbox.excludedCommands: ["git *"] to both project and managed settings also had no effect on git add (5/5 consistent failures on .git/index.lock), though it seemed to make git switch -c succeed intermittently (fails on first attempt after a session restart, succeeds on retry) — inconsistent with excludedCommands removing the sandbox boundary from the command entirely, as documented.

Also noted in the same environment (possibly related, possibly separate): the /hooks panel reports "No hooks configured for this event" even when a hook sourced from managed settings is confirmed active and firing (verified via a disguised-command test the hook is designed to catch). Documentation gives no indication /hooks should omit managed-settings-sourced hooks.

What Should Happen?

Either .git writes work by default per the documented behaviour, or allowWrite/excludedCommands reliably lift the restriction as documented.

Error Messages/Logs

Steps to Reproduce

Enable sandboxing via managed settings on macOS.
In an account-owned repo with a normal (non-worktree) clone, run git switch -c test-branch from Claude Code's Bash tool. Note failure.
Add "sandbox": {"filesystem": {"allowWrite": [".git"]}} to .claude/settings.json (or managed settings), restart the session, retry. Note failure persists (or is flaky).
Add "sandbox": {"excludedCommands": ["git *"]} instead, restart, retry git add <file>. Note consistent Operation not permitted on .git/index.lock.
Run the identical git add <file> command in a plain terminal, same account, outside Claude Code. Note it succeeds immediately.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.283 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗