upvote

points

by cozzyd20 hours ago |
comments
upvoteby enduser19 hours ago|
next
[-]
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)
reply
upvoteby fc417fc80218 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.
reply
upvoteby ihattendorf17 hours ago|
parent|
next
[-]
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.
reply
upvoteby erinnh16 hours ago|
parent|
prev|
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.
reply
upvoteby AnotherGoodName20 hours ago|
prev|
next
[-]
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.
reply
upvoteby throwaway673420 hours ago|
parent|
[-]
https://docs.docker.com/ai/sandboxes/ Any idea on how that compares to this docker feature in development?
reply
upvoteby figmert19 hours ago|
parent|
[-]
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.

reply
upvoteby ray_v20 hours ago|
prev|
[-]
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
reply