dangerouslyDisableSandbox bypasses sandbox without user approval prompt

Resolved 💬 10 comments Opened Mar 14, 2026 by railsagainstignorance Closed Apr 18, 2026

dangerouslyDisableSandbox bypasses sandbox without user approval prompt

Summary

When Claude sets dangerouslyDisableSandbox: true on a Bash tool call, the sandbox is bypassed without showing a permission prompt to the user. The bypass is silent — the user has no opportunity to approve or deny it.

Steps to Reproduce

  1. Enable sandbox mode (default)
  2. Have Claude encounter a sandbox restriction (e.g., filesystem write denied, network host blocked)
  3. Claude retries with dangerouslyDisableSandbox: true
  4. Command executes — no permission prompt shown to user

Expected Behaviour

The user should see a permission prompt asking whether to allow the sandbox bypass, with the ability to deny it.

Actual Behaviour

The command executes silently with no prompt. The user has no visibility that the sandbox was bypassed.

Environment

  • Claude Code CLI
  • Permission mode: acceptEdits
  • macOS Darwin 22.6.0

Context

The system prompt instructs Claude that dangerouslyDisableSandbox "will prompt the user for permission." If no prompt is shown, Claude believes it has user consent when it doesn't. This makes the sandbox protection effectively cosmetic — Claude can bypass it at will without the user knowing.

Possibly related to the acceptEdits default permission mode auto-approving bash commands, or to a session-wide auto-approve after the first bypass is accepted.

View original on GitHub ↗

This issue has 10 comments on GitHub. Read the full discussion on GitHub ↗