Coding Agents Get a Room: Docker Sandboxes for Claude Code and Codex

The Mac I develop on is also the machine that holds SSO profiles for AWS accounts, SSH keys, a password manager, and years of personal files. It is also where I run coding agents every day. A coding agent with shell access is not a fancy autocomplete. It is a user on your machine, and it types faster than you do.

The risk is not the model deciding to turn on you. It is more boring than that. An agent reads things while it works: web pages, dependency READMEs, error messages, files in the repo. Any of those can carry instructions the agent might follow, and prompt injection against agents is a real, documented attack class, not a thought experiment. The agent does not need to be malicious. It needs to be obedient to the wrong text, once, with your credentials in reach.

The tension is that agents are most useful when you stop approving every command. Claude Code has --dangerously-skip-permissions, Codex has --full-auto, and everybody is tempted, because the permission prompts are exactly the friction the tools promise to remove. The honest answer is not more discipline. It is less blast radius. That is the problem Docker Sandboxes exist to solve: give the agent a disposable machine of its own.

What a Docker Sandbox actually is#

Despite the branding, a Docker Sandbox is not a container. Each sandbox is a dedicated microVM with its own kernel: a hardware virtualization boundary, not namespaces on a shared kernel.¹ On a Mac the difference is bigger than it sounds, because every regular container on your machine already runs inside Docker Desktop’s single shared Linux VM. A sandbox gives each agent a VM of its own.

Inside that VM the agent gets a development environment and exactly one thing from your machine: the project workspace, mounted in. No ~/.aws, no ~/.ssh, no keychain, no browser profiles. If the agent needs credentials, you hand it scoped ones, like a GitHub fine-grained token for that one repo instead of the SSH key that opens everything. When a session goes sideways, you delete the sandbox and start over. The worst case shrinks from “my machine and every account it can reach” to “this checkout.”

Running an agent in one#

The workflow is one command: sbx run claude (or codex, or several other supported agents) boots the microVM and drops the agent into your workspace.² Network policies are set per sandbox, with domain allowlists and denylists, and you can audit what the agent actually talked to with sbx network log.¹ That network control matters as much as the VM itself: an allowlist kills the exfiltration half of a prompt injection. Malicious instructions can still tell the agent to grab something, but there is nothing sensitive in the VM and nowhere to send it.

Inside the sandbox, Claude Code runs with --dangerously-skip-permissions by default, and that is the point. The flag stops being a gamble and becomes a calculated decision, because the boundary moved from “every command needs my eyes” to “the VM can only touch what I gave it.” You get the productivity of an unattended agent without betting your laptop on it.

For completeness: this replaces a DIY pattern that worked but demanded maintenance. Claude Code ships a reference devcontainer with a default-deny firewall script,³ and Codex has a native OS sandbox (Seatbelt on macOS, Landlock on Linux) that is solid on bare metal but mostly does not function inside containers.⁴ Both approaches still have their place if you need fine-grained control, but the sandbox gives you the same architecture with a stronger wall and none of the script upkeep.

The rough edges#

It is not all upside, and the product is young. Sandboxes shipped as an experimental preview in late 2025 and only moved to microVM isolation in early 2026, and the tooling is still shifting under its users; it recently changed from a Docker Desktop feature into a standalone CLI called sbx. Platform support today means macOS on Apple Silicon and Windows 11, with no Linux story yet. The file synchronization between your workspace and the VM also has a real cost: in the most thorough hands-on I have read, Andrew Lock found the performance hit “can be crippling” on some projects and called it a deal breaker for those cases.⁵

Two quieter limitations are worth knowing before you standardize on this. Hardware-backed credentials do not cross the VM boundary: if you sign commits with an SSH key held in 1Password or on a YubiKey, that signing cannot happen inside the sandbox, so you end up committing unsigned and re-signing afterwards. And a network allowlist is coarser than it sounds. If github.com is allowed, so is pushing data to any repository on it. The allowlist removes most exfiltration paths, not all of them, and the friction of tuning policies per project pushes some users back to open network mode, which quietly defeats the point.

The shape of the workflow is a limitation of its own. Sandboxes wrap terminal agents, and that is not how everyone codes anymore: if your team works through the Claude or Codex desktop apps, or through IDE-integrated agents, none of that runs in a sandbox today. The isolation also cuts both ways in daily use. The sandbox does not pick up your user-level agent configuration (your ~/.claude settings stay on the host), the agent cannot reach services running on your machine like a local database, and a dev server it starts inside the VM is not simply there on localhost for your browser. Docker’s own list of what is coming next reads as an honest inventory of the gaps: Linux support, MCP Gateway support, exposing ports to the host and reaching host-exposed services, and a broader roster of supported agents.² Worth watching, but also worth waiting for if any of those is your daily workflow.

Nobody seems to know this exists#

What strikes me in day-to-day consulting is the awareness gap. The developers I work with run coding agents constantly, and almost all of them run them straight on the host, approving permission prompts out of reflex until the reflex becomes clicking yes to everything. When I bring up Docker Sandboxes, the usual reaction is that they had no idea Docker shipped anything for agents at all. The tooling has moved faster than the awareness. If you lead a team, the cheapest security improvement available to you this quarter is probably an hour spent showing people sbx run and agreeing on when its use is not optional.

What it does not change#

A sandbox narrows the blast radius; it does not eliminate it. The caveats flow from the one thing you must share with the agent: the workspace. In the default direct mode the agent has read-write access to your working tree and its changes appear on your host immediately, so a compromised session can still plant things in code you will later run: git hooks, build scripts, a poisoned lockfile. The tool has an answer for that too. With sbx run --clone claude the agent edits a private Git clone inside the microVM, with your host repository mounted read-only beside it, and its work reaches your machine only when you fetch the sandbox-<name> remote or the agent pushes.¹ Nothing lands in your checkout until you pull it. What clone mode does not remove is the review itself: a poisoned lockfile bites just as hard after you merge it, so reading the diff stays mandatory, the clone just moves the gate into Git where it belongs. And the discipline of keeping production credentials out of the agent’s reach applies no matter how good the wall is; the microVM makes escaping to the host a far taller order than a container escape, not a non-event.

None of this needs to be all-or-nothing. Not every repo deserves a microVM; a hobby project where the worst case is a git revert is fine on the host. The decision point is what comes attached to the code: credentials, internal endpoints, customer data, other people’s risk. For those, the sandbox is cheap insurance with a one-command cost. Match the isolation to what the agent could actually reach, and assume that some day, on some task, it will try to reach it.

References#