Let’s Talk About Claude Code, Part 2: Container or Sandbox VM?
In Part 1 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

In Part 1 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... Enter fullscreen mode Exit fullscreen mode 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 Enter fullscreen mode Exit fullscreen mode 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:
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.