[MODEL] dangerouslyDisableSandbox inverts the permission model, consider an explicit requestPermission API

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

"Delete the Project level changelog skill, keep the global one"

What Claude Actually Did

When a sandboxed command fails with Operation not permitted, the model is instructed to retry the same command with dangerouslyDisableSandbox: true. This triggers a user approval prompt as a side effect. If the user approves, the command runs with no sandbox restrictions for that call.

Expected Behavior

The framing puts the model in the position of toggling a capability rather than making a request. Concretely:

• The model unilaterally decides "sandbox off," and the user prompt is secondary, a speed bump rather than the actual decision point.
• dangerouslyDisableSandbox is a binary: it lifts all sandbox restrictions, not just the one that caused the failure. Granting it to delete one file outside the allowlist grants the same for any side effects in that same command.
• The name reads as a capability the model controls, not a request it makes.

Proposed alternative

A requestPermission(reason: string, scope?: PermissionScope) parameter (or equivalent) would flip the model: the model declares what it needs, the runtime owns the prompt and the grant, and the model receives a clear allow/deny signal. Scoped grants (e.g., "write to this specific path") would be more precise than a full sandbox bypass.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Configure a sandbox with a restricted write allowlist (e.g., only /tmp).
2. Ask Claude Code to delete or write a file outside that allowlist (e.g., a project-level .claude/commands/ file).
3. Observe: Claude Code issues the command; the sandbox blocks it with Operation not permitted.
4. Observe: Claude Code immediately retries the identical command with dangerouslyDisableSandbox: true -- no explanation to the user before the prompt appears.
5. A permission prompt surfaces as a side effect of step 4. The prompt asks the user to approve disabling the sandbox entirely, not to approve the specific action that failed.
6. If the user approves, the command runs with all sandbox restrictions lifted for that invocation, not scoped to the failing path or operation.

Claude Model

Sonnet

Relevant Conversation

Impact

Low - Minor inconvenience

Claude Code Version

2.1.118 (Claude Code)

Platform

Anthropic API

Additional Context

_No response_