Let’s Talk About Claude Code, Part 2: Container or Sandbox VM?

A developer detailed why they run Claude Code agents inside Docker Sandboxes (sbx) microVMs rather than plain dev containers, arguing that containers share the host kernel and typically require mounting the Docker socket, which effectively hands the agent the whole machine. The sbx approach gives each agent its own kernel and Docker engine, with outbound traffic gated by a network policy and git credentials injected by a proxy so tokens never sit inside the VM.

In Part 1 https://dev.to/bmillerz/lets-talk-about-claude-code-part-1-where-is-your-agent-actually-running-35ff I said every project of mine now runs in a Docker Sandbox, and I promised to explain why I picked that over a plain dev container. A dev container is a big step up from running an agent straight on your laptop. It stops the agent wandering into your other repos and your ~/.ssh . It still leaves two gaps. A container shares your machine's kernel. If anything breaks out, it lands on your host, with all the credentials from Part 1 sitting there. Most of my projects need Docker for Postgres, Redis and Mailpit. Giving an agent Docker from inside a container usually means mounting the Docker socket: docker run -v /var/run/docker.sock:/var/run/docker.sock ... That effectively hands the agent your machine. Anything that can talk to the socket can start a privileged container with your whole filesystem mounted, and you're back where Part 1 started. Docker Sandboxes sbx gives each agent its own microVM, with its own kernel and its own Docker engine. The agent can run the whole stack without touching mine. Outbound traffic goes through a network policy, so I decide what it can talk to: sbx policy allow network registry.npmjs.org,packagist.org sbx policy log what was blocked, and why Git credentials are injected by the proxy, so the token never sits inside the VM. As I said in Part 1, sbx skips permission prompts by default. That doesn't cure the habit of approving on autopilot. It replaces the prompts with a hard boundary, so the boundary has to be right. Part 1 covered the obvious one: the project folder is shared, so the agent can break anything in it. Two less obvious ones: .git folder is as easy to do as a deleted file. Push to a remote often, not just commit. package.json scripts and build config all run on your machine the next time you use them outside the sandbox. Review what changed before you run it there. If that worries you, sbx has a clone mode --clone . The agent works in its own git clone, and nothing reaches your checkout until you fetch it. Network rules: what your agent should be allowed to reach. If you're already sandboxing agents, what's on your allowlist? I'm curious where people draw the line on package registries and third-party APIs.