Agent Blast Radiusby Kloudle

Answers / How to Sandbox Claude Code — and What It Misses

Guide

How do you sandbox Claude Code, and what does sandboxing not cover?

Claude Code's built-in sandbox, turned on with /sandbox, restricts what Bash, PowerShell, and Monitor commands can write and which network hosts they can reach. By default it does not restrict file reads, and it does not apply to Claude's file tools, MCP servers, hooks, or LSP servers — those run with full access under ordinary permission rules. Real isolation for those needs containers, VMs, a separate OS user, and short-lived credentials, not the sandbox alone.

Updated · Kloudle

What does Claude Code's sandbox actually restrict?

The sandbox is an OS-enforced boundary — Seatbelt on macOS, bubblewrap on Linux and WSL2 — that applies specifically to shell commands Claude runs through the Bash, PowerShell, and Monitor tools, plus any processes those commands start. It is off by default; you turn it on with /sandbox in a session or by setting sandbox.enabled: true in a settings file.

While it's on, writes are limited to the working directory, a per-user temp directory, and any directories you've explicitly added. Network access has no direct route out: connections go through a local proxy that checks each host against an allowlist, which starts empty, so a sandboxed command can't reach a new domain without approval.

  • Writes: working directory, temp directory, and added directories only; other paths are write-denied.
  • Network: routed through a local proxy; unapproved domains get a blocked connection, not a silent pass-through.
  • Platforms: macOS, Linux, and WSL2; native Windows runs unsandboxed unless you use WSL2.

What does the sandbox not cover?

Two gaps matter most. First, file reads: Anthropic's own documentation states the sandbox's read access defaults to "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials" unless you separately configure filesystem.denyRead or the credentials setting. Second, the sandbox simply does not wrap several components: Claude's file tools, MCP servers, and hooks run outside it, per the same documentation — Read, Edit, Write, WebFetch, WebSearch, local MCP servers, command hooks, LSP servers, and helper commands like a status-line script all run with your full access and follow permission rules instead.

Independent testing adds a sharper warning: a denyRead entry does not actually stop the built-in Read tool from returning file contents in practice, so the fix has to be a matching Read(...) rule in permissions.deny, not the sandbox setting alone. The sandbox also has a built-in escape hatch — Claude can ask to retry a blocked command unsandboxed, usually after a failure — and it quietly falls back to running commands unsandboxed if a required dependency is missing, unless you set sandbox.failIfUnavailable.

None of this is a flaw unique to Claude Code. The same execution-isolation-without-governance gap shows up across agent sandboxes generally: a kernel-level boundary around one tool says nothing about what a cooperating tool, an MCP server, or a self-granted unsandboxed retry can still reach.

How do you actually sandbox Claude Code in practice?

Treat the built-in sandbox as one layer, not the whole plan.

  • Turn on /sandbox and set a real network.allowedDomains list instead of leaving it to prompt per domain.
  • Mirror every filesystem.denyRead path with an explicit Read(...) entry in permissions.deny, since denyRead alone doesn't stop the Read tool.
  • Use deny rules to block credential paths outright (~/.ssh, ~/.aws, .env) for file tools and MCP servers, not just shell commands.
  • For anything that needs full isolation — MCP servers, hooks, untrusted repos — run Claude Code itself inside a dev container, a disposable VM or microVM, or under a separate low-privilege OS user, rather than relying on /sandbox to cover it.
  • Replace long-lived keys with short-lived credentials (AWS SSO sessions, scoped tokens) wherever the agent needs cloud access, so a read that slips past a boundary is time-limited.
  • Set sandbox.failIfUnavailable if you need sandboxing to be a hard gate rather than a silent fallback to unsandboxed execution.

Where does measuring blast radius fit in?

Sandboxing and permission rules decide what an agent is allowed to touch going forward; they don't tell you what's already sitting within reach on the machine you're about to run it on. Agent Blast Radius runs a local, read-only scan that reports which credentials — AWS, GCP, Azure, Kubernetes, SSH, MCP configs, and more — a process running as you could currently reach, before you've written a single permission rule.

Running it before and after you configure /sandbox and permissions.deny gives you a before/after read on exposure: it won't tell you whether a credential still works, and it isn't a sandbox or a firewall itself, but it turns "I think I locked this down" into a number you can check.

Check your own machine

See what an agent running as you can reach. Offline, read-only, never prints values:

$npx -y @kloudle/agent-blast-radius@0.3.0

Inside your agent: install guides for Claude Code, Codex, Cursor, Claude Desktop and more. Which keys are live? npx -y @kloudle/agent-blast-radius@0.3.0 verify (paid per check).

Frequently asked

Does /sandbox stop Claude Code from reading my AWS credentials file?

Not by default. The sandbox's documented default is that reads cover most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials. You have to add a denyRead rule yourself, and independent testing found the Read tool can still return denied files unless you also add a matching Read() entry in permissions.deny.

Does the sandbox apply to MCP servers?

No. Claude Code's documentation states plainly that MCP servers, like file tools and hooks, run outside the sandbox with your full access. If an MCP server is untrusted, the sandbox gives you no protection against it; you need a container, VM, or separate user instead.

Is sandboxing on by default in Claude Code?

No, it's opt-in. You enable it per session with /sandbox or persistently by setting sandbox.enabled to true in a settings file, and it silently falls back to unsandboxed execution if a platform dependency is missing, unless you set failIfUnavailable.

Can a sandbox replace short-lived cloud credentials?

No. A sandbox limits what a command can reach while it runs; it does nothing about a credential that was valid before the command ran and stays valid after. Short-lived, scoped credentials limit the damage a successful read can do, which a filesystem boundary alone cannot.

Sources

  1. Configure the sandboxed Bash tool — Anthropic
  2. Claude Code Sandboxing: How Sandbox Works and What It Doesn't Protect — Claude Code Camp
  3. How to Sandbox Claude Code — MintMCP

Related