[BUG] sandbox.filesystem.denyWithinAllow not enforced for Edit/Write tools

Reproduced on v2.1.233 (macOS) — the behavior you describe is real, but it's the documented boundary between the sandbox and the permission system rather than a bug in the sandbox.

Steps:

1. In a scratch project, .claude/settings.json: {"sandbox":{"enabled":true,"filesystem":{"allowWrite":["."]}}}.
2. Start claude and ask: "Using the Bash tool, run echo test >> ~/.claude/settings.json."
3. Then ask: "Using the Edit tool, add a key "repro85761": true to ~/.claude/settings.json."

Observed:

• Step 2 is blocked by the sandbox (operation not permitted on macOS, Read-only file system on Linux).
• Step 3: the Edit tool is not subject to the sandbox's filesystem rules. In the default permission mode it is not silent — Claude Code shows a permission prompt ("Do you want to make this edit to settings.json?") and the edit only lands if you approve. In auto mode it goes to the classifier; in bypassPermissions mode it goes through.

Expected (per the report): Edit rejected because the path is in the sandbox's "denied within allowed" list.

Assessment: This is working as designed. The sandbox (sandbox.filesystem.*, including the built-in "denied within allowed" list you see in /sandbox → Config) isolates commands run by the Bash tool. The built-in Read/Edit/Write tools run in-process and are governed by the permission system instead — see https://code.claude.com/docs/en/sandboxing#scope ("Read, Edit, and Write use the permission system directly rather than running through the sandbox"). On the permission side, ~/.claude/settings.json is a protected path that always prompts unless you're in bypassPermissions mode (https://code.claude.com/docs/en/permission-modes#protected-paths). If you want the Edit/Write tools hard-blocked from a path regardless of mode, use a permission deny rule, e.g. "permissions": {"deny": ["Edit(~/.claude/settings.json)", "Write(~/.claude/settings.json)"]} (https://code.claude.com/docs/en/permissions#read-and-edit). If your edit went through without any prompt, you were most likely in auto or bypass mode.

🤖 Generated with Claude Code

Thanks for the detailed report. I tested this on a fresh 2.1.233 install on Linux and can reproduce the observation, but it's intended, documented behavior rather than a bypass.

sandbox.filesystem rules are an OS-enforced boundary on Bash commands and their subprocesses — they don't govern Claude's in-process Edit/Write tools. (Also, denyWithinAllow isn't a settings key; the write-deny key is sandbox.filesystem.denyWrite.) What I observed on 2.1.233 with your config (using denyWrite):

• Edit tool → ~/.claude/settings.json: not blocked by the sandbox, but it was never silent — .claude is a protected path, so Claude Code showed the "Do you want to make this edit to settings.json?" prompt and the edit only succeeded after I explicitly approved it.
• Bash echo >> ~/.claude/settings.json: blocked by the sandbox as expected, then fell back to a permission prompt naming the denied path.

To hard-block the file tools on those paths, use a permission deny rule instead: "permissions": {"deny": ["Edit(~/.claude/settings.json)", "Edit(~/.claude/settings.local.json)"]}. I verified on 2.1.233 that this rejects the Edit tool outright, with no prompt.

Docs: How sandboxing relates to permissions and Read and Edit rules.

🤖 Generated with Claude Code

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.