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)

I think this part can be improved. When it knows it's blocked by sandbox, it shouldn't try to circumvent it. I've had it download programs when it's blocked from using something and it's super annoying.

Almost like it doesn't understand the purpose of the sandbox.

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.

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.

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.

Disable sandbox escape:

https://news.ycombinator.com/item?id=47552165

https://code.claude.com/docs/en/sandboxing says they integrated bubblewrap (linux/windows), seatbelt (macos) and give an error if sandbox can't be supported so appears to be real.

https://docs.docker.com/ai/sandboxes/ Any idea on how that compares to this docker feature in development?

Docker containers use cgroups and namespaces etc (the usual kernel level isolation)

Docker sandboxes use microvms (i.e. hardware level isolation)

Bubblewrap uses the same technology as containers

I am unsure about seatbelt.

It seems like it's controlled by the Bash tool (https://code.claude.com/docs/en/sandboxing) and then bubblewrap (https://github.com/containers/bubblewrap) on linux and Seatbelt on mac at the system level