[Bug] Auto mode bypasses manual permission prompt for dangerouslyDisableSandbox commands

Bug Description
Title: Auto mode bypasses the manual permission prompt for dangerouslyDisableSandbox Description Per the documented behavior of the sandbox escape hatch: ▎ When a command fails due to sandbox restrictions (such as network connectivity issues or incompatible tools), Claude is prompted to analyze the failure and may retry the command with the dangerouslyDisableSandbox parameter. Commands that use this parameter go through the normal Claude Code permissions flow requiring user permission to execute. In auto mode, this manual permission step appears to be bypassed — dangerouslyDisableSandbox: true Bash calls are auto-approved alongside other "safe" commands by auto mode's classifier, with no prompt shown to the user. The user has no visibility into the fact that their session is escaping the sandbox. Why it matters The sandbox escape hatch is the boundary between "Claude operating under the user's chosen safety profile" and "Claude operating with full user privileges". The documented manual prompt is the user's only visibility into when that boundary is crossed. Auto mode pre-approving these defeats the purpose of having an escape hatch with a confirmation gate. The current escape valve users have is to set sandbox.allowUnsandboxedCommands: false, which disables the escape hatch entirely. That's a blunt instrument — it forces a binary choice between "no escape hatch ever" and "escape hatch with a confirmation that auto mode silently swallows". Expected Auto mode's classifier should treat any Bash call with dangerouslyDisableSandbox: true as inherently in the "ask" / "manual confirmation required" category, regardless of how innocuous the underlying command looks. The same should apply to any other tool call that crosses a security boundary. Suggested fix In auto mode's pre-execution classification, add an unconditional rule: if the tool input contains dangerouslyDisableSandbox: true, route to the manual confirmation flow even if the command would otherwise be auto-approved. The user explicitly opted into auto mode for normal commands; sandbox escape isn't normal.

Environment Info

• Platform: darwin
• Terminal: tmux
• Version: 2.1.119
• Feedback ID: 7b339849-882f-498e-8844-8abffdb614b5

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/johkjo/.local/share/claude/versions/2.1.119 (expected in multi-process scenarios)\n    at mH6 (/$bunfs/root/src/entrypoints/cli.js:2736:2177)\n    at E$8 (/$bunfs/root/src/entrypoints/cli.js:2736:1257)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-27T11:51:01.708Z"},{"error":"AxiosError: Request failed with status code 404\n    at zl (/$bunfs/root/src/entrypoints/cli.js:114:1194)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:119:12696)\n    at emit (node:events:92:22)\n    at endReadableNT (internal:streams/readable:865:50)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:121:2467)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-27T12:32:31.355Z"}]