Claude Code sandbox: /sandbox, sandbox.enabled, allowedDomains, excludedCommands and strict mode

/sandbox

{
  "sandbox": {
    "enabled": true
  }
}

• macOS: uses the built-in Seatbelt framework, no setup needed.
• Linux and WSL2: needs bubblewrap and socat, for example sudo apt-get install bubblewrap socat. The /sandbox panel shows a Dependencies tab when something is missing.
• Native Windows: commands run unsandboxed. Run Claude Code inside WSL2 to use the sandbox.

• Writes: the working directory, a per-user temp directory and directories added with --add-dir, /add-dir or permissions.additionalDirectories. Change with sandbox.filesystem.allowWrite and denyWrite.
• Reads: most of the machine, including ~/.ssh and ~/.aws/credentials. Block paths with sandbox.filesystem.denyRead.
• Network: no direct route out. Traffic goes through a local proxy that checks each host against sandbox.network.allowedDomains, which starts empty. Block hosts with deniedDomains.
• Environment variables: inherited from Claude Code, including secrets.

The sandbox covers shell commands only. Read, Edit, Write, WebFetch and WebSearch follow permission rules instead, and hooks, local MCP servers and your status line command run with your full access.

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

• Filesystem lists from several settings scopes are merged, not replaced.
• Tools that read HTTP_PROXY and HTTPS_PROXY, such as curl, npm and git over HTTPS, work once their host is allowed. Plain ssh, most database drivers, UDP and ping cannot connect from the sandbox.
• Set sandbox.network.strictAllowlist to true (in user, managed or --settings settings) to deny unlisted hosts instead of prompting.

• Auto-allow: a command that runs inside the sandbox is approved with no prompt, even in Manual mode. Bash deny rules, content-scoped ask rules such as Bash(git push *) and rm on critical paths still apply.
• Regular permissions: every Bash command goes through the normal permission flow, sandboxed or not.
• autoAllowBashIfSandboxed defaults to true. Set it to false to be prompted for sandboxed commands.

Use sandbox.excludedCommands for a trusted tool that cannot work inside the sandbox. docker is incompatible with the sandbox, so the docs suggest a narrow pattern.

{
  "sandbox": {
    "enabled": true,
    "excludedCommands": ["docker compose *"]
  }
}

• Patterns use Bash(...) rule syntax: docker matches only bare docker, docker * matches it with any arguments.
• Every command in a chained call must match, so npm ci && docker compose build stays sandboxed unless npm ci is also excluded.
• When a command fails in the sandbox, Claude may retry it with dangerouslyDisableSandbox. Manual and acceptEdits modes prompt, auto mode sends it to the classifier, dontAsk denies it and bypassPermissions runs it.

Set allowUnsandboxedCommands to false to turn off the unsandboxed retry. Add failIfUnavailable so Claude Code does not run commands unsandboxed when the sandbox cannot start. The /sandbox Overrides tab shows this as Strict sandbox mode.

claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}'

Some paths stay write-protected even inside allowed directories, including .claude settings files, .claude/skills, .claude/agents, .claude/hooks, .mcp.json, shell startup files, .gitconfig and hooks and config inside .git. allowWrite cannot lift this.