Claude Code security in 2026: sandbox ladder, credentials, and when /sandbox is not enough

The more permission dialogs you click through, the less you read them. Claude Code’s OS-level Bash sandbox (filesystem isolation plus network isolation) cut those prompts by about 84% in Anthropic’s internal usage, and it keeps a prompt-injected agent inside boundaries the kernel enforces. Mid-2026 added sandbox.credentials, managed lockdown keys, and a documented isolation ladder. One catch still trips people: /sandbox wraps Bash only. Read, Edit, MCP, and hooks stay on the host until you climb that ladder.

Definitions

Permission rules - allow / ask / deny checks that decide whether a tool may run at all (Bash, Read, Edit, WebFetch, MCP, and others). Evaluated before the tool runs. See the tools inventory and ToolName(specifier) rules.

Bash sandbox (/sandbox) - OS-level filesystem and network restrictions on Bash commands and every child process they spawn. Seatbelt on macOS; bubblewrap on Linux and WSL2. Native Windows is unsupported; use WSL2 or a container.

Sandbox runtime - @anthropic-ai/sandbox-runtime, which wraps the entire Claude Code process (file tools, MCP, hooks) in the same Seatbelt/bubblewrap primitives.

MCP - Model Context Protocol; the standard for third-party tool servers the agent can call. Each server is code you run alongside Claude Code.

Approval fatigue - rubber-stamping dialogs until they stop being a control and become noise. Sandboxing replaces per-command “may I?” with boundaries you declare once.

Why prompts are not enough

Claude Code starts read-only. Safe commands such as ls, cat, and git status run without a prompt; most mutating Bash still needs approval. Fine as a default. Broken as your only control after fifty approvals in an hour.

Prompt injection makes the gap concrete. Malicious text in a README, a fetched page, or a dependency can steer the agent toward curl, credential reads, or shell-config writes. Claude Code mitigates some of that: it sanitizes input, never auto-approves network commands, keeps WebFetch results in an isolated context, and asks about (rather than runs) any command its rules do not match. No model is injection-proof. The useful question is: if the agent is compromised, what can it still touch?

Anthropic’s answer is two boundaries that must both hold:

Skip network isolation and an agent that can still read ~/.ssh can ship the keys out. Skip filesystem isolation and it can backdoor a tool that later gets network access. You need both.

The isolation ladder (2026)

Match the threat to the boundary. Climb when you skip prompts or touch untrusted code.

--dangerously-skip-permissions and long auto-mode sessions remove the human gate. Anthropic’s guidance: put those sessions in a container, a VM, or the sandbox runtime. Bash sandbox alone is not that boundary. Plan mode’s “read-only” promise is behavioral, not sandboxed. OS isolation is the hard layer.

Scope gap that bites

Claude Code recognizes common file commands inside Bash (cat, sed, grep) and applies your Read/Edit deny rules to them too. A Python one-liner that opens ~/.ssh/id_rsa is not recognized, so it walks past those rules. OS sandbox plus sandbox.credentials closes that hole for Bash; permission denies close it for the Read tool. Set both.

Enable and configure /sandbox

/sandbox

Pick auto-allow (sandboxed Bash runs without prompts; out-of-bound access falls back to the normal permission flow) or regular permissions (isolation stays, every command still asks). On Linux/WSL2 install bubblewrap and socat first. macOS uses Seatbelt with nothing extra. WSL1 and native Windows are unsupported.

Defaults that matter:

• Write: working directory + session $TMPDIR only
• Read: nearly the whole machine, including credential files, unless you deny them
• Network: no domains pre-allowed; the first time a command needs a new host, Claude Code prompts (from v2.1.191, approving keeps that host for the rest of the session)
• Escape hatch: on sandbox failure Claude may retry with dangerouslyDisableSandbox (still goes through permissions). Set allowUnsandboxedCommands: false for strict mode

Project-local mode lands in .claude/settings.local.json (not committed). User-wide: sandbox.enabled: true in ~/.claude/settings.json. Orgs use managed settings.

Close the credential hole (v2.1.187+)

Default read policy was the quiet failure mode through early 2026: writes locked, reads wide open. sandbox.credentials groups file denies and env scrubbing. Deny entries merge across scopes - project, user, and managed; a project or user scope cannot loosen a deny that managed settings set.

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org", "api.github.com"]
    }
  },
  "permissions": {
    "deny": ["Read(~/.ssh/**)", "Read(~/.aws/**)", "Read(./.env*)"]
  }
}

Notes:

• There is no built-in credential deny list. Empty credentials protects nothing.
• mask (v2.1.199+) substitutes a sentinel inside the sandbox and injects the real secret only on listed injectHosts. It requires network.tlsTerminate. Mask entries in project settings are ignored; use user, managed, or CLI settings.
• Broad allowlists like github.com still leave room for domain fronting - smuggling traffic to a blocked host behind an allowed hostname. The default proxy only checks the hostname the client claims; it does not look inside the encrypted traffic. If you need content inspection, terminate TLS at a custom proxy.
• Never allow /var/run/docker.sock through allowUnixSockets. That is host access via Docker.

To scrub Anthropic and cloud-provider credentials from the environment of every subprocess (sandboxed or not), set CLAUDE_CODE_SUBPROCESS_ENV_SCRUB.

Org lockdown

Managed settings can require the sandbox and refuse soft fallback:

excludedCommands still merges from every scope, so a developer can always append tools that run outside the sandbox. Keep the managed list narrow (docker * is a common necessary exception).

Cloud sessions add another tier. Each Claude Code on the web run is an Anthropic-managed VM with network controls, a Git proxy that keeps real tokens outside the sandbox, branch-restricted push, audit logs, and automatic cleanup. Remote Control - the phone/web UI that drives Claude Code on your own machine - is different: it talks to a local process, with no cloud VM and no Anthropic-managed sandbox.

What still sits outside the sandbox

Treat these as product limits, not bugs:

• MCP servers. Put them on allowlists. Anthropic does not security-audit third-party servers. Prefer servers you wrote or trust; gate them with permission rules.
• /security-review and PR review actions. Useful first pass. Outside evaluations (including Semgrep’s) find inconsistency and blind spots on multi-file and business-logic issues. Pair with deterministic static and dynamic analysis (SAST/DAST) tools.
• Windows WebDAV. Avoid enabling WebDAV or \\* paths; they can trigger remote requests that bypass the permission system.
• Home-directory trust. Claude Code asks you to trust a folder before working in it. Starting in ~ extends that trust to everything under your home directory for the session - that trust resets the next time you launch Claude Code. Start from a project subdirectory instead.
• Data plane. Isolation does not change what is sent to the model API. Sandbox controls local blast radius, not training or privacy policy.

Practical playbook

1. Trusted personal repo, interactive: /sandbox auto-allow + credential denies + narrow allowedDomains
2. Team laptop fleet: managed enabled + failIfUnavailable + allowUnsandboxedCommands: false + sandbox.credentials for AWS/SSH/tokens
3. Unattended / skip-permissions: container, VM, or npx @anthropic-ai/sandbox-runtime claude with write/network allowlists that include the project, ~/.claude, and api.anthropic.com
4. Untrusted repository: dedicated VM or Claude Code on the web; do not rely on Bash sandbox alone
5. Always: review suggested commands; deny curl/wget if your threat model requires it; audit with /permissions; keep SAST in CI

Slash commands for the control surface: /sandbox and /permissions. Details in the commands cheatsheet.

Bottom line

Permission rules decide whether a tool runs. The Bash sandbox decides what a running shell can touch. Containers and VMs decide whether the whole agent (including Read and MCP) shares your host. Turn on /sandbox, deny credential reads, and climb the ladder the moment you remove the human from the approval loop.