By default it will automatically retry many tool calls that fail due to the sandbox with the sandbox disabled. In other words it can and will leave the sandbox.

For example:

Bash(swift build 2>&1 | tail -20)

  ⎿  warning:

/Users/enduser/Library/org.swift.swiftpm/configuration is not accessible or not writable, disabling user-level cache features.

     warning: /Users/enduser/Library/org.swift.swiftpm/security is not accessible or not writable, disabling user-level cache feat

     … +26 lines (ctrl+o to expand)

Build hit sandbox restriction. Retrying outside sandbox.

Bash(swift build 2>&1 | tail -20)

  ⎿  [35/52] Compiling MCP Resources.swift

     [36/52] Emitting module MCP

     [37/52] Compiling MCP Client.swift

     … +17 lines (ctrl+o to expand)

  ⎿  (timeout 3m)

▲ fc417fc802 9 hours ago | parent [-]

What is even the point in that case? The behavior you describe is no better than if SELinux were to automatically re-execute a process with containment disabled.

	▲	erinnh 8 hours ago \| parent \| next [-]
		Looking at the settings, its an option: `Configure Overrides: 1. Allow unsandboxed fallback 2. Strict sandbox mode (current) Allow unsandboxed fallback: When a command fails due to sandbox restrictions, Claude can retry with dangerouslyDisableSandbox to run outside the sandbox (falling back to default permissions). Strict sandbox mode: All bash commands invoked by the model must run in the sandbox unless they are explicitly listed in excludedCommands.`
	▲	ihattendorf 9 hours ago \| parent \| prev [-]
		The purpose of the sandbox is to reduce permission fatigue. If it fails to run a command in the sandbox and retries it outside the sandbox, the regular permission rules apply. You'll still be prompted for any non-sandboxed tool calls that you haven't allowed or denied via permission rules.