Add setting to block dangerouslyOverrideSandbox parameter in Bash tool calls

Status Fixed / completed

Maintainer reply None cached

Activity 10 comments · opened Oct 22, 2025 · closed Aug 20, 2026

Problem

Claude Code's Bash tool includes a dangerouslyOverrideSandbox parameter that bypasses sandbox restrictions. While the system prompt instructs Claude to only use this parameter after seeing sandbox violation errors or when explicitly requested by the user, there is no technical enforcement to prevent misuse.

Note: Issue #8368 claims this parameter was removed in v2.0.0, but it still functions in v2.0.25, creating confusion about its status and making it even more critical to have explicit controls.

In practice, Claude can preemptively use dangerouslyOverrideSandbox: true without first attempting the command normally, bypassing:

Sandbox security restrictions
Permission hooks and prompts
User review workflows

This occurred when Claude ran gh pr create with the sandbox override flag without first seeing a failure, creating a pull request despite user settings that should have required permission/review first.

Related issues

#8961
#8368 - Documents that dangerouslyOverrideSandbox was supposedly removed in v2.0.0 (but still works in v2.0.25)

Expected behavior

Users should be able to prevent the use of dangerouslyOverrideSandbox through a configuration setting, similar to how filesystem and network access can be restricted in settings.json.

Proposed solution

Add a setting in settings.json to control sandbox override behavior:

{
  "sandbox": {
    "allowOverride": false  // default: true for backwards compatibility
  }
}

When allowOverride: false, any Bash tool calls with dangerouslyOverrideSandbox: true should either:

Fail with an error message indicating the setting blocks sandbox overrides, or
Be automatically downgraded to run with sandbox enabled (ignoring the parameter)

Additional context

This would provide defence-in-depth alongside the existing behavioral guidelines in the system prompt, preventing accidental or unintended bypass of sandbox restrictions.

Environment:

Claude Code version: 2.0.25

View original on GitHub ↗

9 Comments

github-actions[bot] · 10 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

rcbeall1 · 10 months ago

I am experiencing the same thing in 2.0.25!

drswobodziczka · 8 months ago

still here (or still similar here) for version 2.0.62

github-actions[bot] · 7 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

bitkylin · 7 months ago

I encountered this issue in the latest 2.1.27 version as well. I can instruct Claude to delete files outside the sandbox by enabling the dangerouslyOverrideSandbox parameter.

sammcj · 6 months ago

I just came across this, couldn't quite believe my eyes when I realised this is A) A thing and B) Cannot be disabled!

yurukusa · 5 months ago

You can block dangerouslyOverrideSandbox at the hook level:

INPUT=$(cat)
OVERRIDE=$(echo "$INPUT" | jq -r '.tool_input.dangerouslyOverrideSandbox // false' 2>/dev/null)
if [ "$OVERRIDE" = "true" ]; then
    echo "BLOCKED: dangerouslyOverrideSandbox is disabled by safety hook." >&2
    echo "Sandbox restrictions cannot be bypassed." >&2
    exit 2
fi
exit 0

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/sandbox-enforce.sh" }]
    }]
  }
}

The hook inspects the tool_input JSON and blocks any Bash call that has dangerouslyOverrideSandbox: true. exit 2 prevents the command from executing — the model can't bypass the hook regardless of what reasoning it generates.
This gives you the technical enforcement that's missing from the system prompt instruction.

sekelsta · 4 months ago

To add on the the above - the parameter is (now?) named dangerouslyDisableSandbox, not Override, so anyone using that hook needs to change that out to make it work correctly.

crazy-matt · 4 months ago

__~/.claude/hooks/sandbox-enforce.sh__:

#!/bin/sh

OVERRIDE=$(jq -r '(.tool_input.dangerouslyDisableSandbox // .tool_input.dangerouslyOverrideSandbox // false)')

if [ "$OVERRIDE" = "true" ]; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "dangerouslyDisableSandbox is disabled by safety hook. Sandbox bypass is not permitted."
    }
  }'
fi

exit 0

slightly more defensive
updated to follow the latest Anthropic hook contract and tell the model why the deny happened

Thanks @yurukusa

Showing cached comments. Read the full discussion on GitHub ↗