Trust but Sandbox

• Coding agents can do almost anything locally that you can, and their behavior is hard to predict. That is why real isolation beats endless confirmation prompts.
• Docker Sandboxes (sbx) deliver exactly that out of the box: MicroVM isolation from the host, file access limited to the project directory, granular network policies, and a proxy that hides credentials from the agent.
• This combination makes YOLO mode (--dangerously-skip-permissions) largely safe to use and supports nine agents, including Claude Code, Codex, and Copilot.
• sbx is still young (a moving target, license not final) and occasionally awkward, but it offers far more security with far less effort than containers or agent-side sandbox features.

My colleague Joy Heron recently described in „I sandboxed my coding agents“ how she built her own isolated environment for her coding agents. Her takeaway: it works, but the setup costs time. There is now a ready-made tool for this: Docker Sandboxes, or sbx for short. It works out of the box and is dead simple to use. Before I show what sbx actually does, it is worth taking a closer look at the problem.

Agents can do (almost) everything

A local agent can run almost anything and access almost everything that the user who started it can. You could argue that this is true in principle for any binary you launch. But an agent’s behavior is largely determined by the underlying model, which makes it hard to predict or audit. On top of that, agents are creative. The confirmation prompts before critical actions (like “Should I run this command?”) are at least hard-wired into the client code. But such prompts don’t sit well with autonomy, and after a while nobody reads them carefully anymore. They also don’t protect you from agents getting very creative when it serves their idea of the goal. It happened to me: I watched my agent installing an office suite on my Mac, something I had even approved beforehand, even though I didn’t actually want it. It would be better to define clear rules up front and then let the agent work. Beyond file access, the same applies to network usage.

Docker Sandboxes (sbx) as a ready-made solution

sbx is a tool from Docker Inc. Despite the name, it is not based on containers, but on MicroVMs. That means no shared kernel with the host, yet still little overhead, far more lightweight than a classic VM. On top of that come plenty of well-thought-out conventions that make everyday use easy. The tool is still relatively young and has only just left its early-access phase. It is not open source, but according to Docker it will remain free to use, including commercially, for good.

Where does sbx actually help?

Area	Protection
File system	Only the mounted project directory is accessible
Network	Configurable policies (Open / Balanced / Locked Down)
Credentials	A proxy on the host injects tokens, so they are never visible inside the VM itself
Host system	Fully isolated from the VM

sbx protects the host machine, limits access to a single directory, and lets you control network access granularly via policy instead of leaving it entirely to the agent. That gives you the tools to control at least parts of the risk triangle Simon Willison calls the “Lethal Trifecta”. This combination of isolation, credential proxy, and network policies offers, in my view, enough control to enable so-called YOLO mode largely without risk. In fact, --dangerously-skip-permissions, as Claude calls it, is even the default in sbx. sbx currently supports nine agents (as of July 2026), including Claude Code, Codex, and Copilot. Other agents such as pi can be used just as well via custom images.

Notable features

One simple but very useful feature is that the paths inside the sandbox match the paths outside, even though only the project directory is visible inside the sandbox. This lets you use absolute paths, for example in local config files. VMs are created ad hoc when you start an agent via sbx. There is a slick overview in an ASCII dashboard. In it you can list, start, stop, and delete all VMs, as well as inspect proxy usage and edit network rules.

To hide the credentials for accessing APIs (for the model or for MCP servers, say) from the agent, the proxy injects the authentication tokens into the calls. As a result, you only have to log in once with a provider and are then authenticated across all VMs. ### Pros and cons **Pros:** -Strong isolation while still keeping overhead low (MicroVM, not a container) -The directory path is identical in the VM and on the host, which is very handy day to day -Ready-made templates for Claude, Codex, and other agents -A proxy for network access hides credentials and tokens from the agent -Network policies can be configured in fine-grained detail -VMs are created on the fly -A dedicated Docker host runs inside the VM, so no Docker-in-Docker is needed when the agent itself needs to run tests or builds -An ASCII dashboard gives you an overview at all times, including proxy and network policies -The agent itself can be customized (for example with Claude)

Cons:

• Still very new: there are new builds regularly; stable, but a moving target
• The license is not final yet, though the CLI will presumably remain free to use
• If you have many projects, you also end up with many VMs
• VMs have to be updated individually (how much of this can be automated is still open)
• There is not yet a way to hide or mask individual files in the project folder from the agent; symlinks remain the workaround
• The isolation is inconvenient in places: the IDE runs on the host, the agent in the VM. The directory is shared, but the network is separate, which occasionally gets in the way
• Copy and paste is cumbersome depending on the host operating system

How the alternatives compare

Docker containers. Containers share the kernel with the host, so the isolation is weaker than with a MicroVM. There is also no dedicated Docker daemon, so container builds would again require Docker-in-Docker. You have to build a ready-made agent template or a credential proxy yourself. Doable, but considerably more effort for less security. Claude --sandbox. An agent-side feature, not system-wide protection, and in practice it didn’t work for me the way it was described anyway. It restricts tool use within the agent, but offers no real isolation and no protection against prompt injection from external sources. On top of that comes vendor lock-in to Claude. Cloud sandboxes like GitHub Codespaces or E2B.dev. These provide real isolation in the cloud, and therefore no local risk, but also no access to local resources such as your own file system or local services. Latency and cost depend on usage.

Configuration and customization

sbx can be customized per project: agent settings (a .claude or .agent folder including skills, say) simply go into the project directory and give the agent context and boundaries. The network policy can be overridden per project, and the status bar or the behavior of the agent itself can be adjusted too. If you like, you can build your own sandboxes based on other images or other agents, for pi for instance. But I’ll only mention that briefly here, as it would go beyond the scope of this post.

Further topics

sbx is constantly evolving and already offers more useful features than this article can cover. Two of them are worth a closer look:

• Kits: your own customizations of the sandbox environments
• the git clone mode: the sandbox works on its own clone instead of directly on the project directory

Other features are only announced or still missing. Pasting images via copy and paste is already described in the documentation, but not yet implemented. Being able to hide files via a blacklist, for example a .env file, would certainly still be useful.

If you are interested in sandboxing coding agents in general, github.com/restyler/awesome-sandbox offers a good overview of further approaches.