[Bug] Sandbox blocks cwd-tracking writes on macOS, causing all bash commands to exit with code 1
Bug Description
Description:
When sandboxing is enabled (auto-allow mode) on macOS, every bash command fails with exit code 1 and the following error:
zsh:1: operation not permitted: /tmp/claude-502/cwd-<hash>
This occurs even for commands with no filesystem side effects (e.g., echo "hello"). The command itself executes and returns correct
output, but zsh exits with code 1 due to the sandbox blocking writes to the cwd-tracking file.
Steps to reproduce:
- Enable sandbox (auto-allow mode) via /sandbox
- Run any bash command, e.g. echo "hello"
- Observe exit code 1 and zsh: operation not permitted: /tmp/claude-502/cwd-<hash> in stderr
Expected behavior:
Claude Code's internal cwd-tracking mechanism (/tmp/claude-{uid}/cwd-*) should be whitelisted in the sandbox policy by default,
since it is an internal implementation detail of the Bash tool itself.
Attempted workaround:
Adding the following to settings.json does not resolve the issue:
"sandbox": {
"filesystem": {
"allowWrite": [
"//tmp/claude-502/**",
"//private/tmp/claude-502/**"
]
}
} The internal sandbox policy includes denyWithinAllow: ["/"] which appears to override user-configured allowWrite entries for paths
under /, making it impossible to whitelist this path from settings.json.
Environment:
- macOS (Seatbelt sandbox)
- Sandbox mode: auto-allow
Environment Info
- Platform: darwin
- Terminal: iTerm.app
- Version: 2.1.72
- Feedback ID: 1f2ecb6e-095b-4c5a-9bc9-067122a12e96
Errors
[]
8 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This sandbox blocking issue on macOS is a common pain point. In OpenClaw, we implemented a tiered sandbox approach:
For the cwd-tracking issue specifically:
The key insight is that most sandbox blockers are false positives.
---
OpenClaw - Open source desktop AI assistant
hit this exact issue on macOS. every bash command returning exit code 1 even though the output is correct is incredibly confusing to debug because your scripts appear to work but any conditional logic (set -e, if command, etc) breaks silently. the zsh operation not permitted on the cwd-tracking file is the giveaway. in the meantime, running without sandbox mode and using a hook-based permission system instead was our workaround
Our macOS automation MCP server that works without sandboxing by using accessibility APIs directly: https://github.com/mediar-ai/mcp-server-macos-use/blob/main/Sources/MCPServer/main.swift
Instead of sandboxing bash commands, we route automation through the accessibility API which has its own TCC permission model. Avoids the cwd-tracking conflict entirely.
not stale
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Pretty messed up that this gets closed while basic security sandboxing is basically broken on a major, supported OS...
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.