Sandbox your AI coding agent: what the container protects, and what it never will

You did what the tutorial said. The agent runs in a container now, permission prompts switched off, and the worst case is supposed to be that the box trashes itself.

Then Monday morning someone asks why main lost four commits.

At 01:12 the agent hit a rebase conflict, decided the clean fix was to put the branch back to a state it knew worked, and pushed. It could, because the command that started the container carried this:

docker run -v ~/.ssh:/root/.ssh -v $PWD:/workspace my-agent-image

The container did its job perfectly. It kept the agent off your host filesystem all night, and it handed over your push credentials, because without them the session would have been useless.

A sandbox limits what an agent reaches by accident. It has nothing to say about what you deliberately put inside it.

What a coding agent sandbox actually protects

Plenty, and it is worth being precise. Inside a container, a mistimed rm -rf stops at the mount. A global package install, a rewritten shell profile, a migration run against the wrong database: all of it lands somewhere disposable, so a wrecked environment costs a rebuild instead of an afternoon.

That disposability buys the thing you actually want, which is fewer interruptions. Anthropic's guide to choosing a sandbox puts isolation exactly where the prompts stop: it matters most "when you let Claude work with fewer permission prompts, run it unattended, or point it at code you do not fully trust". With no prompts left to catch mistakes, the boundary you chose is what protects your system.

The container is not paranoia. It is what makes unattended runs reasonable at all.

Everything you mount into the box is outside the box

A useful sandbox is a leaky one by design. Four things cross the boundary in almost every real setup.

Your repository, mounted writable, because otherwise there is no work. The agent can still rewrite your tree and your history, so branch hygiene and a worktree per agent matter inside a container exactly as much as outside one.

Your credentials: SSH keys for push, a gh token, a cloud profile, the .env you copied in so the integration tests would pass. Each was mounted for a good reason, and together they are the answer to "what can go wrong". Guardrails put it best: an agent told not to touch production has a preference, an agent without the credential has a constraint.

The network. Default container networking is unrestricted egress, and the docs say the quiet part plainly: any approach that allows network egress can still leak data the agent can read. Full outbound access stops filesystem damage and permits exfiltration.

The model. Isolation does not change what is sent to the API. Your prompts and every file the agent reads leave the machine either way.

Pick the isolation level from the session, not the tool

There is no single right container, there is a ladder. Take the lowest rung that survives the worst thing tonight's session is allowed to do.

Per-command sandbox. Claude Code's built-in /sandbox uses OS primitives (Seatbelt on macOS, bubblewrap on Linux and WSL2) to fence each Bash command. Immediate, but it covers Bash only: MCP servers and hooks are separate processes and still run on your host. Fine for supervised work, not enough for anything unattended.

Whole-process isolation without Docker. The @anthropic-ai/sandbox-runtime package wraps the entire process, so tools, hooks and MCP servers land inside the same boundary. It denies writes and network by default, so you allowlist the project directory, the config paths and the API domain up front. Still a research preview, so treat its config as moving ground.

A dev container. The full environment, standardized in your repo so every developer and every runner gets the same one. The example dev container Anthropic publishes ships a default-deny iptables firewall, and that firewall, not the container, is what makes running without prompts defensible.

A virtual machine. Its own kernel, for code you did not write and do not trust: an unfamiliar repo, a dependency you are evaluating.

Hosted options start at the top of that ladder, which is why background agents feel both safe and remote: strong isolation and no access to your running services are one property described twice.

Isolation is one layer of four

Sandboxing gets sold as a complete answer and it is a quarter of one. Four controls answer four different questions:

• Permissions decide whether an action runs at all: guardrails and blast radius.
• Isolation decides what it can reach once it does: this post.
• Egress policy decides what can leave, the only layer that touches prompt injection: an instruction smuggled in through a fetched page still needs somewhere to send what it takes.
• Review decides what you keep, and reading the diff is still the only layer that catches code that is merely wrong.

Three of them fail quietly. Only the last one has a human in it.

Where sandboxing coding agents goes wrong

You now maintain two environments. The suite is green in the box and red on your machine, or the reverse, and the agent starts editing working code to satisfy a broken image.

The setup tax gets paid in tokens. An agent dropped into a half-built image spends its first twenty minutes installing things and guessing at versions, once per session. Pin the image and treat it as code.

The mounts creep back. You add ~/.ssh for push, then ~/.aws for one script, then the host Docker socket because the tests need it. Every step is reasonable and the end state is your laptop with extra steps. Write down what is mounted and reread that list monthly.

Some work cannot happen in there: your running database, your device, the dev server a browser test drives. Either you network it back in, reopening the boundary, or that task stays on the host.

And the honest limit, in the docs' own words: sandbox isolation reduces the impact of a breach, it does not eliminate risk.

A desk where each session's boundary is visible

Isolation is a per-session decision, and per-session decisions are what get lost when agents live in a dozen terminal tabs.

SanuDesk is a desktop app for that. Your Claude Code, Codex and Gemini sessions tile into one grid, each workspace pinned to a single project folder, so the pane running unattended tonight sits beside the supervised one instead of behind an editor. Work arrives from a Kanban board: deploy a card and it opens a fresh session briefed with it, so the launch you standardized is the launch every task gets. Recurring unattended passes become a Loop, journaled per run, so the job that most deserves a hardened environment is the one you can prove ran. It drives the model subscriptions you already pay for, and the grid and board are in the free plan (pricing).

Read your own run command tonight

Find the exact command that starts your agent: the docker run line, the devcontainer.json, or nothing at all. Ask it three questions.

What is mounted writable? Which credentials are reachable from inside? What can it reach on the network?

If the honest answer to all three is "everything", you do not have a sandbox, you have a container, and the gap between those is four commits at 01:12. Close one of the three tonight, usually egress, usually the cheapest, and you are ahead of any policy document.

Download SanuDesk free to keep every agent session in its own visible workspace, or see how the grid, the board and Loops fit together on the features page.