Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [MODEL] dangerouslyDisableSandbox inverts the permission model, consider an explicit requestPermission API [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#56066•Fetched 2026-05-05 05:59:05
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
ude-benude-ben
Participants
ude-benude-ben
Timeline (top)
labeled ×4renamed ×1

Code Example



---
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues for similar behavior reports
  • 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

extent analysis

TL;DR

Implement a requestPermission parameter to flip the model's behavior from unilaterally deciding to disable the sandbox to requesting permission from the user.

Guidance

  • Introduce a requestPermission function that takes a reason and an optional scope parameter to allow the model to declare its needs and receive a clear allow/deny signal.
  • Modify the model to use the requestPermission function instead of retrying the command with dangerouslyDisableSandbox: true.
  • Update the runtime to own the prompt and grant permissions, rather than the model controlling the sandbox.
  • Consider implementing scoped grants to allow for more precise permission control.

Example

// Proposed alternative
function requestPermission(reason: string, scope?: PermissionScope) {
  // Implementation to request permission from the user and return a clear allow/deny signal
}

Notes

The current implementation of dangerouslyDisableSandbox lifts all sandbox restrictions, which may not be the intended behavior. The proposed requestPermission function aims to address this issue by providing a more fine-grained permission control.

Recommendation

Apply workaround: Implement the requestPermission function to improve the model's behavior and provide more precise permission control. This approach allows for a more user-centric permission flow and reduces the risk of unintended sandbox bypasses.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#cache issue#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [MODEL] dangerouslyDisableSandbox inverts the permission model, consider an explicit requestPermission API [1 participants]