Claude Code sandbox: what it isolates, and what it leaves to rules

The Claude Code sandbox is an operating system boundary around the commands Claude Code runs, which limits the files they can write and the hosts they can reach. It is switched on with /sandbox, and it lets Claude Code run more commands without asking because the damage any one of them can do is smaller.

A sandbox answers where a command can reach. It does not answer whether a particular action should happen, such as a push to main from inside the repository it is allowed to write. This page covers both, and how they fit.

How the Claude Code sandbox works

According to Claude Code's sandboxing docs:

	What it does
What it wraps	Bash, PowerShell and Monitor commands, and every process they start
macOS	the built-in Seatbelt framework
Linux and WSL2	bubblewrap for files, and socat to route network traffic
Writes	the working directory, added directories and a temporary directory, and nowhere else
Reads	most of the machine, apart from the paths you deny
Network	no host is allowed at first, and Claude Code asks the first time a command needs one

The settings live under sandbox in settings.json: sandbox.enabled, sandbox.filesystem.allowWrite and denyRead, sandbox.network.allowedDomains, and sandbox.credentials for the credential files and variables to protect.

One setting is worth knowing before you rely on it. A command that fails inside the sandbox can be retried outside it, through the dangerouslyDisableSandbox parameter. Set sandbox.allowUnsandboxedCommands to false to keep every command inside.

Three ways to put an agent in a box

	Claude Code `/sandbox`	Dev container	`memnox run --untrusted`
Works for	Claude Code	any agent inside it	any agent you start through it
Held by	Seatbelt or bubblewrap	the container runtime	Seatbelt on macOS, Landlock on Linux
Your credentials	protected where `sandbox.credentials` or a deny names them	absent unless mounted	unreadable
Network	asks per new host	whatever the container allows	only through the session's egress proxy, which asks for unknown hosts
An outward or destructive action inside the box	left to Claude Code's permissions	left to the agent's permissions	asks first

A container is the strongest wall and the most setup, and it leaves you working in a second environment. The Claude Code sandbox is the lightest and covers one agent. memnox run --untrusted is meant for a freshly cloned repository that nobody has vouched for:

bash

memnox run --untrusted -- claude

Writes stay in the repository, credentials and dotfiles in your home directory are unreadable, the network goes through the session's own egress proxy, and every outward or destructive action asks. On macOS Seatbelt holds all of it. On Linux Landlock holds the files, and TCP from Linux 6.7, and the start screen says plainly what the kernel cannot hold. Untrusted repositories and new agents has the full detail.

What a sandbox cannot decide

A sandbox limits reach. Inside that reach, every command is equal. These are all inside a typical sandbox for a repository:

git push --force origin main
rm -rf src/
a migration run against the database whose credentials are in .env
a deploy through a CLI that is already logged in

Deciding those is a rule's job, not a wall's. Memnox answers every tool call with allow, ask or deny before it runs, in Claude Code, Codex, Cursor, Gemini CLI and Windsurf, and a deny names what to do instead:

verdict     DENY
reason      you chose to deny this: it rewrites history somebody else may already have pulled
instead     push a branch and open a PR

Use both. The sandbox makes a mistake smaller, and the rules stop the mistakes you can name before they happen. If one gets through anyway, memnox rewind puts the working tree back to before the agent touched it.

Questions people ask

How do I turn on the Claude Code sandbox?

Run /sandbox inside Claude Code and choose the mode, or set sandbox.enabled in settings.json. On Linux and WSL2 it needs bubblewrap and socat installed.

Does the Claude Code sandbox protect my SSH keys?

Only the ones it is told about. Reads are open across most of the machine, so name the paths in sandbox.credentials or sandbox.filesystem.denyRead, or run the agent with memnox run --untrusted, where credentials are unreadable.

Is a sandbox enough to run an agent unattended?

It limits how far a mistake reaches, not which mistakes happen inside that reach. Pair it with rules that deny the actions you never want, and a way to undo what an agent changed.

Can I sandbox Cursor or Codex the same way?

Codex has its own sandbox modes. For any agent, memnox run --untrusted starts it inside the same kernel wall, and a dev container works for all of them.