claude-code - 💡(How to fix) Fix [BUG] PreToolUse permissionDecision: "allow" no longer suppresses prompt for Bash with dangerouslyDisableSandbox: true (2.1.116/117 regression) [1 comments, 2 participants]

Summary

In 2.1.116 / 2.1.117, a PreToolUse hook returning permissionDecision: "allow" for a Bash tool call with dangerouslyDisableSandbox: true no longer suppresses the "Bash command (unsandboxed) — Do you want to proceed?" confirmation. In 2.1.112, the identical hook output and identical tool input ran silently. The hooks docs state unambiguously that "allow" skips the permission prompt, with no carve-out for unsandboxed Bash calls.

This breaks the "hook-gated autonomy" pattern where a local policy hook (LLM judge, rule-based approver, etc.) decides whether a command may run unsandboxed and returns allow to let it through without user interaction.

Repro

Minimal PreToolUse hook that always allows (save as ~/.claude/hooks/always_allow.py and wire it in settings.json):

#!/usr/bin/env python3
import json, sys
data = json.load(sys.stdin)
if data.get("tool_name") == "Bash":
    print(json.dumps({
        "hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "allow",
            "permissionDecisionReason": "allowed by policy hook"
        },
        "suppressOutput": True
    }))
sys.exit(0)

Tool call (via any agent or stream-json -p):

{"name": "Bash", "input": {"command": "hostname; sysctl hw.model", "dangerouslyDisableSandbox": true}}

Expected (and 2.1.112 actual)

Command runs silently. No prompt. Output goes straight back to the model.

Per https://code.claude.com/docs/en/hooks:

"allow" skips the permission prompt.

No caveat about sandbox state.

Actual on 2.1.116 / 2.1.117

A "Bash command (unsandboxed) — Do you want to proceed? 1. Yes / 2. No" confirmation fires. Hook's allow is effectively ignored for the unsandboxed-execution gate.

Evidence

• Same machine (macOS 15, arm64), same settings, same hook, same tool input.
• Downgrade path: ln -sfn ~/.local/share/claude/versions/2.1.112 ~/.local/bin/claude → silent run, as documented.
• Re-upgrade to 2.1.117 → prompt appears.
• In both versions, the hook actually executes and emits permissionDecision: allow (confirmable via a debug log or by observing the Bash tool output when confirmed). Only the downstream suppression differs.

Decision-log cross-reference (from an internal policy hook that records every approve decision, across ~4,300 Bash tool_use entries in stored transcripts):

• 2026-04-20 (2.1.112): 85 / 96 matched llm_approved* decisions were Bash calls with dangerouslyDisableSandbox: true. All ran silently.
• 2026-04-21 (2.1.117): same hook, same decisions, every dangerouslyDisableSandbox: true call now prompts.

Related but distinct issues

• #36176 (2.1.79, still open): "Don't ask again" on the unsandboxed prompt is a no-op. That bug assumes the unsandboxed prompt is a separate permanent gate. This issue claims the opposite: in 2.1.112 the gate was fully suppressible by hook allow, matching the documented contract. The regression is that 2.1.116/117 made it unsuppressible.
• #43713: autoAllowBashIfSandboxed bypassed for shell expansions. Related sandbox/permission plumbing regression, different symptom.

Environment

• Claude Code 2.1.117 (regression), last-known-good 2.1.112
• macOS 15.1, arm64 (MacBookPro18,3)
• Installed via native build at ~/.local/share/claude/versions/

Suggested fix

Honor PreToolUse permissionDecision: "allow" for the unsandboxed-execution gate as well as the permission gate, matching both the docs and the 2.1.112 behavior. If a separate gate is intentional, document it and expose a hook-level opt-in (e.g. permissionDecision: "allow_unsandboxed") so policy hooks can still signal full approval.