dangerouslyDisableSandbox bypasses sandbox without user approval prompt
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
- Enable sandbox mode (default)
- Have Claude encounter a sandbox restriction (e.g., filesystem write denied, network host blocked)
- Claude retries with
dangerouslyDisableSandbox: true - 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.
This issue has 10 comments on GitHub. Read the full discussion on GitHub ↗