Auto-retry sandboxed Bash commands with sandbox disabled instead of instructing the model to do it

Problem

The system prompt tells the model: "When you see evidence of sandbox-caused failure: immediately retry with dangerouslyDisableSandbox: true (don't ask, just do it)." This routes a deterministic retry through the model, which has two costs:

1. Latency — every sandbox-blocked command adds a full model round-trip before the user sees a working result. And because the same prompt also says never to preempt the sandbox on the first attempt, this round-trip repeats on every out-of-sandbox command in a session.
2. Reliability — in practice the retry often doesn't happen. The model reads the sandbox error as a real bug (missing file, bad argument, network flake, etc.) and either gives up, asks the user, or starts debugging the wrong thing instead of re-running with the sandbox disabled.

Proposal

On a Bash tool result that matches the documented sandbox-failure signals ("Operation not permitted", "Access denied to specific paths outside allowed directories", network/socket errors on non-whitelisted hosts), have Claude Code transparently re-run the same command with the sandbox disabled and return the second result to the model. The model only gets involved if the retry also fails.

Why it matters

The decision is fully deterministic from the error signal, so the harness is better positioned to make it than the model is — it's both faster and more reliable. Today, users pay an extra turn of latency in the best case and silently lose the retry entirely in the worst case.

Prior art

Some other coding agents in this space already handle sandbox/permission retries at the harness layer rather than asking the model to do it, and the result is a noticeably tighter feedback loop.