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 leaves two gaps.

Gap 1: the kernel is shared

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.

Gap 2: Docker inside Docker

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.

How sbx closes both

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.

The trade-off

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.

Where the boundary stops

Part 1 covered the obvious one: the project folder is shared, so the agent can break anything in it. Two less obvious ones:

• That includes git history. A reset or a deleted .git folder is as easy to do as a deleted file. Push to a remote often, not just commit.
• Files it writes can run on your host. Git hooks, 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.

Next up

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.