[FEATURE] Make sandbox escape hatch opt-in and add audit logging

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The dangerouslyDisableSandbox escape hatch is currently enabled by default (allowUnsandboxedCommands: true). When a sandboxed command fails, Claude can analyze the failure and retry with sandbox protections bypassed.

While this improves usability by handling edge cases automatically, the default-on behavior creates security concerns:

1. User awareness gap: Users enabling sandboxing for security may not realize there's an escape hatch that Claude can trigger
2. Approval fatigue risk: The bypass goes through "normal permissions flow" - the same flow users click through repeatedly. A request to "retry outside sandbox" may not receive the scrutiny it deserves
3. No audit trail: There's no logging when dangerouslyDisableSandbox is used, making security reviews difficult
4. Enterprise policy friction: Organizations wanting strict sandboxing must explicitly configure allowUnsandboxedCommands: false on every installation

The current default prioritizes convenience over security-by-default, which contradicts the sandboxing feature's core purpose.

Proposed Solution

1. Change the default to opt-in

Change allowUnsandboxedCommands default from true to false.

Users who want the convenience of automatic sandbox escaping can explicitly enable it:

{
  "sandbox": {
    "allowUnsandboxedCommands": true
  }
}

2. Add distinct approval UI for sandbox escapes

When dangerouslyDisableSandbox is requested, present a differentiated prompt that:

• Clearly states "This command will run OUTSIDE the sandbox"
• Shows what sandbox restrictions are being bypassed
• Requires a distinct confirmation (not just the normal "allow" button)

3. Add audit logging for sandbox escapes

Log all dangerouslyDisableSandbox usages with:

• Timestamp
• Command that was executed
• Reason for sandbox escape (the failure that triggered it)
• Whether user approved or denied

This enables security teams to review sandbox escape patterns.

Alternative Solutions

Current workaround: Set "allowUnsandboxedCommands": false in settings.json. This works but:

• Requires users to know the setting exists
• Must be configured on each installation
• No audit trail even when enabled

Use excludedCommands for known incompatible tools: This is already recommended (e.g., docker), but doesn't help with unexpected sandbox failures.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Scenario: Security-conscious developer enables sandboxing

1. Developer reads about sandboxing feature, understands it provides filesystem/network isolation
2. Developer enables sandboxing via /sandbox command, expecting protection
3. Days later, a build script fails inside the sandbox due to network restrictions
4. Claude automatically retries with dangerouslyDisableSandbox
5. Developer clicks "allow" on what looks like a normal permission prompt
6. Command runs with full system access - no sandbox protection
7. Developer is unaware the sandbox was bypassed
8. Weeks later, a security audit has no record of when/why sandbox escapes occurred

With proposed changes:

• Step 4: Claude cannot bypass sandbox (default is off)
• OR if opt-in enabled: A distinct, alarming prompt appears explaining the sandbox will be bypassed
• Step 6: Audit log records the escape with full context

Additional Context

Documentation references:

• Sandboxing docs: https://code.claude.com/en/sandboxing (Note section after "Configure sandboxing")
• Settings reference: https://code.claude.com/en/settings#sandbox-settings

Current documentation excerpt:

"Claude Code includes an intentional escape hatch mechanism that allows commands to run outside the sandbox when necessary. 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."

Security principle: Defense-in-depth configurations should be secure by default. Users should opt into reduced security, not opt out of it.

Mirror location: code-claude/docs/en/sandboxing.md (lines 120-124), code-claude/docs/en/settings.md (line 277)