[BUG] Permission prompts fire inside sandbox-allowed paths, training users to add permissions.allow entries that genuinely bypass the sandbox

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?

The permission prompt layer intercepts operations that the sandbox has already approved, then offers permissions.allow as the escape hatch. This is backwards: permissions.allow entries bypass the sandbox entirely and apply globally across all projects, but the friction that drives users toward them is friction from sandbox-safe operations, not sandbox-escaping ones.

Write/delete asymmetry (same root cause)

• Writing a file into the project tree: no prompt (sandbox allows it)
• Deleting that same file with rm: always prompts (rm:* is a hardcoded default, path-agnostic)
• Result: there is no ephemeral scratch space where an agent can freely create and clean up temporary files. Skills either leak files permanently or force a cleanup prompt on every run.

The asymmetry is particularly sharp because rm on a sandbox-writable path is strictly less dangerous than the write that preceded it — you cannot delete a file the sandbox did not allow you to create.

What Should Happen?

Permission prompts fire when a command would escape the sandbox boundary — when it targets a path not in the sandbox write allowlist, or attempts a network operation to a non-allowlisted host.

In-sandbox operations on allowlisted paths run without prompting. The rm:* default should be path-aware: deleting within sandbox-writable paths should not require confirmation.

Suggested fix direction

The sandbox allowlist and the permission prompt layer need to be aware of each other. An operation should pass the permission layer without prompting if and only if its target path is already within the sandbox write allowlist (for filesystem operations) or the network allowlist (for network operations). The rm default rule should check path against the sandbox write allowlist before prompting.

Error Messages/Logs

Permission prompts fire on any command not in permissions.allow, regardless of whether the sandbox has already approved the target path. The rm:* rule applies unconditionally. The only documented escape is adding permissions.allow entries that disable sandbox containment entirely.

Steps to Reproduce

A skill runs jq ... > /tmp/claude/output.json. The sandbox write allowlist already includes /tmp/claude. The operation is safe. But jq isn't in permissions.allow, so it triggers a permission prompt anyway. The natural response — add Bash(jq *) to ~/.claude/settings.json — runs all future jq invocations outside the sandbox, across every project on the machine, forever. The prompt designed to prevent unsafe behavior directly causes unsafe behavior.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.191 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

Related open issues

• #52322: allowWrite does not permit unlink/rm on macOS
• #43096: Sandbox cannot create its own TMPDIR
• #51373: Sandboxing docs overstate auto-allow behavior
• #17720: Claude Code leaves temp files