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

Ben Miller — Thu, 05 Nov 2026 16:39:55 +0000

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.

Let's Talk About Claude Code, Part 1: Where Is Your Agent Actually Running?

Ben Miller — Wed, 04 Nov 2026 17:01:17 +0000

I've watched a coding agent wander out of its project folder and start reading other client repos on the same laptop. It wasn't doing anything malicious. It was trying to be helpful. But some of those repos had production credentials in them, and they all got rotated that afternoon.

Most discussion about coding agents is about which model to use. Much less of it covers where the agent runs, and that's where most of the risk is.

What an agent on your host can reach

Run Claude Code directly on your machine and it runs as you. Whatever your user account can read, it can read too, including:

SSH keys in ~/.ssh
Cloud credentials in ~/.aws, ~/.config/gcloud and similar
Every .env file in every project on the disk
Every other repo you've cloned, including ones for other clients

That last one is what caught me out. Nobody worries about the agent reading the repo it's working in. The problem is everything else that happens to be on the same disk.

Why permission prompts aren't enough

Claude Code asks before it runs commands or touches files outside the working directory. That works for the first few prompts. By the fortieth in a session you're approving without reading, or you've turned on skip-permissions so they stop interrupting you.

Prompts depend on a human paying attention every time. That's a weak control to build on.

What I do now

Every project now runs in a Docker Sandbox (sbx). Each agent gets its own microVM, and the only part of my machine it can see is the project folder.

Two things to know before you switch:

sbx starts Claude Code with permission prompts skipped by default. That's deliberate, because the VM is the boundary instead of the prompts. It does mean the agent will act without asking inside the sandbox.
Your project folder is still shared. The agent can delete or break anything in the repo. Commit often, and keep secrets out of the working tree.

Next in the series

Part 2 covers why I went with sbx over a plain dev container, and what a container doesn't protect you from.

How are you running your agents? Directly on the host, in a container, or in a VM? Tell me in the comments.

DEV Community: WaterMill | Digital Agency