{"version":"2.1.305","anchor":"new-sandbox-setting-allownestedusernamespaces","canonical_anchor":"new-sandbox-setting-allownestedusernamespaces","heading":"Nested user namespace sandbox setting now covers WSL and more tools","tier":"use","area":"Sandbox","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.305\/e\/new-sandbox-setting-allownestedusernamespaces","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.305","markdown":"### Nested user namespace sandbox setting now covers WSL and more tools\n\n`sandbox.allowNestedUserNamespaces` now also applies on WSL, names more tools that need it, and stays off by default\n\n**What**\n\nThe `sandbox.allowNestedUserNamespaces` setting lets commands inside the sandbox create their own user namespaces, a Linux feature some programs use to fence themselves off. Its description now:\n\n- covers WSL (Windows Subsystem for Linux) as well as Linux\n\n- lists Chromium and Electron apps, rootless podman and buildah, a nested bubblewrap, and `unshare` as tools that need it\n\n- warns that turning it on removes the sandbox's isolation of the code it runs\n\nIt remains off by default. When Claude Code runs commands through `\/bin\/sh` in the sandbox, it now explicitly turns nested user namespaces off.\n\n**Why**\n\nThe setting is a way to let rootless containers and Chromium-based tools run inside the sandbox, at a stated security cost. Turn it on only when such a tool fails without it.\n\n- Area: Sandbox\n- Names: `sandbox.allowNestedUserNamespaces`\n- Tier: Use it now\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}