Sandbox blocks git reset --hard on tracked files: 'Operation not permitted' for legitimate workspace sync

Description

The Claude Code sandbox write policy blocks git reset --hard origin/<branch> when the working tree contains tracked files (e.g. README.md). This prevents automation frameworks from syncing the local workspace after a GitHub PR merge, which is a legitimate and common post-merge operation.

Error

error: unable to unlink old 'README.md': Operation not permitted
fatal: Could not reset index file to revision 'origin/master'.

Steps to Reproduce

1. In a Claude Code session (default sandbox enabled), run via the Bash tool:

``bash
git fetch origin master && git reset --hard origin/master
``

1. The sandbox blocks the file unlink step with "Operation not permitted".

Expected Behavior

git reset --hard to a remote branch should be permitted in the project's working directory, which is already in the sandbox write allowlist. The operation only modifies tracked files that are explicitly inside the allowed write path.

Actual Behavior

The sandbox blocks unlinking existing tracked files (README.md, etc.) even though the project root is in the write allowlist. This appears to be a more granular restriction on file unlinking/replacement rather than path-level write permission.

Workaround

Invoke the command with dangerouslyDisableSandbox: true. This requires manual intervention and cannot be automated within a normal sandboxed agent loop.

Impact

Post-merge workspace synchronization in agentic orchestration frameworks requires either:

• Manual sandbox bypass (operationally fragile), or
• Graceful degradation with a diverged workspace state

A more targeted sandbox policy that permits git reset --hard within the project's allowed write root would eliminate this class of interruption.

Environment

• Claude Code CLI (macOS, Darwin 25.x)
• Observed during automated PR merge + workspace sync in agentic run sessions