Docker Sandboxes: Is This The One?

In just a few years, AI coding assistants have gone from "aww look, he's trying to code fizz buzz" to "oh crap, we're all going to be jobless". And that's okay, software just happens to be one of the areas where LLMs can add real value. If you've done any pair programming with an agent like Claude, you know that the prompt loops get old. Would you be happy if the new hire asked for permission before every bash command?

As a result, we get complacent. A recent Anthropic blog post shared that users have approved 93% of permission prompts!!!

That's why I am so obsessed with finding the best agent sandbox. Good security should lead to more freedom, not less. This post lays out my current approach to solving that challenge.

Architecture

Every coding agent should live in a dedicated sandbox, but what kind of sandbox is best? There are non-containerized approaches (see Anthropic's Sandbox Runtime), but this just feels leaky.

Containers provide a clean packaging mechanism, and with a sidecar controlling egress and credential brokering, you're left with a nicely defined boundary. However, it's undeniable that the attack surface of a container is vast, as the Linux kernel contains ~41 million lines of code (version 6.17.1). I wouldn't lose sleep if a co-worker used this approach, but I'd also try to nudge them towards the holy grail...

MicroVMs. Dedicated, lightweight, ephemeral, and broker-able. My ideal setup looks like this:

Notice that we still have a proxy and credential broker in place. The MicroVM solves the kernel boundary issue, but it doesn't provide egress control.

Proxy and Credential Broker

You should assume your agents will become tricked or confused. If that happened, what's the worst case scenario? Well, it depends on what the agent has access to (e.g., secrets) and who it can talk to (e.g., allowlists). By attaching a proxy to all of the MicroVM's requests, we can reliably block or rewrite all outbound traffic according to that project's needs.

There are countless open-source and paid tools in this space, and picking the right one depends on your workflow. While I'm usually working on one project and agent at a time, I believe a great solution should scale. I therefore tend to favor a centralized proxy over the sidecar model (i.e., each agent has its own proxy).

Filesystem Mounting

I like having a unified project directory shared between my IDE and the agent. This allows me to follow code changes in real-time and stop agent execution when I notice it's going down the wrong path. As such, virtiofs is a must-have for my use-case.

Remote Control

The majority of new users opt to use a GUI (e.g., Claude Code Desktop) for controlling their agents instead of a CLI. This is a challenge for the above architecture because the GUI tools tend to assume the agent lives on the same host. More recently, AI providers like Anthropic are supporting remote control natively. For Claude Code, this means your agent session can be completely detached from the operator.

In the given architecture, the MicroVM agent owns the session (run claude --remote-control) and exposes it to a cloud endpoint. Operators can then connect to that session from any device (e.g., phone app or IDE) with all communication being established over outbound requests.

Choosing a VMM

The two most popular MicroVM VMMs are Firecracker and Cloud Hypervisor. Firecracker is more performant, but it is limited to raw block devices, which don't meet my filesystem requirements. Cloud Hypervisor trades some of that performance in for a broader featureset, including virtiofs support.

For users that prefer to develop directly on a Mac, Apple introduced their Containerization Framework in 2025, which places each container in its own lightweight virtual machine.

But wouldn't it be great if someone built a tool that was multi-platform and supported all of the above features?

Docker Sandboxes

Finally, Docker Sandboxes are here. The Docker team built their own VMM that can run on Linux, macOS, or Windows. Cross-platform support means I can move my agents back and forth between my cloud VM and MacBook without major re-tooling or architecting.

Here's what my setup looked like:

The devcontainer uses an ordinary bind mount, and the Docker sandbox gets a "direct mount" (virtiofs under the hood). The same working tree stays live for both me and the agent. Keep in mind, all project files are visible to the agent, including whatever is defined in .gitignore.

For egress monitoring, all traffic leaving the MicroVM goes through the proxy (which supports some credential injection). It even comes with 3 built-in network policy modes to help you get started.

Results

As excited as I was, I found this tool to be underwhelming in its current state.

1. You have to log in to Docker to use the tool, and I don't think they do a good job at explaining why.
2. The CLI was unbearably slow, even when no MicroVMs were involved. I'm talking ~1 minute hangs just to see what sandboxes are running.
3. I could not get the sandboxd daemon to run in detached mode. I had to spawn a separate process for it.
4. Credential injection only supports the services and registries they've defined, so you can't set custom header policies.

Even if 1-3 aren't dealbreakers, I believe the last issue is truly blocking safe usage of --dangerously-bypass-permissions (YOLO mode).

The search continues...