Linux sandbox blocks nested user namespaces by default, with a new allowNestedUserNamespaces setting

What

The sandbox is a protected space where Claude Code runs commands with limited access to your files. On Linux it is built with a tool called bubblewrap (bwrap). A user namespace is a Linux feature that lets a program set up its own isolated view of the system, and a sandboxed command that creates one can undo the sandbox's write denies, the rules that stop it writing to certain files.

• A new optional sandbox setting, allowNestedUserNamespaces, defaults to false. Setting it lets sandboxed commands create their own user namespaces, which browser sandboxes, rootless podman or nested bubblewrap need. Its description warns that this gives up the write denies against a hostile command.
• Unless that setting is on or a seccomp helper (a separate system-call filter) is in use, the sandbox adds --disable-userns when the installed bubblewrap supports it.
• To find out, Claude Code runs the bubblewrap binary with --help, waits up to 5 seconds, looks for --disable-userns in the output, and remembers the answer for each binary path.
• Commands are prefixed with SRT_ALLOW_NESTED_USERNS=1 or =0 so the sandbox can apply the choice.
• If neither protection is available, Claude Code warns that bubblewrap needs version 0.8.0 or later, must not be setuid, and must not use enableWeakerNestedSandbox, and that a command creating a user namespace can undo the write denies.
• Deny rules for credential files are now tracked separately and are no longer reopened by allowRead or write paths. Placeholders for deny paths that do not exist were reworked, and mandatory deny rules are now returned and counted.

Why

This closes a route by which a sandboxed command on Linux could escape its write restrictions. If you run browsers, podman or nested bubblewrap inside the sandbox, you now need allowNestedUserNamespaces, at a real security cost.