Sandboxing AI coding agents: containers or microVMs?

1 November 2026

Both work, and both are far better than running an agent with permission prompts off on your own laptop. The difference is the wall. A container shares the host's kernel, so one kernel bug or a careless mount is enough to reach the host. A microVM runs its own kernel behind a hypervisor, so the agent has to break the virtual machine monitor as well. Use a container when you control the code and want speed and low cost; use a microVM when the agent runs unattended with broad permissions, or on a machine that holds things you can't lose.

Why sandbox a coding agent at all?

An agent that asks before every command is slow to work with, so people turn the prompts off. In Claude Code that is --dangerously-skip-permissions, which equals the bypassPermissions mode. From then on the agent can run anything your user can: delete files, rewrite git history, read ~/.ssh and browser profiles, and send data anywhere on the network.

Most of the time it does what you asked. The risk is the rest of the time: a misread instruction, a prompt injection hidden in a web page or a dependency's README, or a confident rm -rf in the wrong directory. A sandbox decides how far a mistake can reach.

What does Claude Code's built-in sandbox do?

Claude Code has its own sandbox for the shell commands it runs. Turn it on with /sandbox in a session. On macOS it uses Seatbelt; on Linux it needs bubblewrap and socat:

sudo apt-get install bubblewrap socat

It limits which files and network hosts those commands can reach. It covers the Bash tool and the processes it starts, not the Claude Code process itself, so Anthropic's docs suggest a container, a virtual machine or their sandbox runtime when you want one boundary around everything.

How do I run an agent in a container?

Anthropic publishes a reference dev container for Claude Code in the anthropics/claude-code repository, with an outbound firewall script and a non-root user. Claude Code refuses --dangerously-skip-permissions when it runs as root, so set a normal user either way.

A minimal do-it-yourself version with Docker:

docker run --rm -it --user node -v "$PWD":/work -w /work node:22 bash

Inside, install your agent, for Claude Code with curl -fsSL https://claude.ai/install.sh | bash, and run it from /work. Three rules matter more than the image:

Mount only the project, never your home directory, ~/.ssh or cloud credential files.
Never mount the Docker socket. Access to it is access to the host.
Limit outbound network traffic if the agent doesn't need the whole internet.

Anthropic's own warning is worth repeating: with permissions skipped, a dev container doesn't stop a malicious project from sending out anything inside the container, including Claude Code's credentials.

Where do containers fall short?

Docker's documentation says it plainly: containers all share the host's kernel, and the default capabilities and mounts may give incomplete isolation, alone or combined with a kernel vulnerability. Every system call the agent makes lands in the same kernel that runs everything else on the machine.

That is acceptable for many uses. It is weaker when the agent runs for hours with no one watching, installs whatever packages it likes, and runs code it found online. gVisor sits in between: it moves the system interfaces into a separate application kernel per sandbox, which shrinks what a container escape can touch.

What does a microVM add?

A microVM is a small virtual machine with its own kernel, started by a minimal virtual machine monitor on top of KVM. Firecracker describes its microVMs as giving "enhanced security and workload isolation over traditional VMs" with the speed of containers. crosvm, the monitor Chrome OS built and Zydra uses, runs each virtual device in its own minijail sandbox, so a bug in one device doesn't hand an attacker the host.

The costs are real but small: more memory per sandbox, a slower start than a container, and more setup than docker run.

You can do this yourself. Trail of Bits' coop is a free, open-source CLI that runs Claude Code and Codex in disposable VMs on your own machine: Firecracker on Linux, Lima with Apple's Virtualization.framework on macOS.

coop setup
coop up
coop claude

Its stated model is "anything the agent does stays in the VM". The agent gets passwordless sudo inside the guest, which is fine, because the guest is the boundary.

What doesn't a sandbox protect?

No sandbox protects what you hand the agent. If the VM holds your GitHub token, the agent can push with it. If it has an API key, it can spend it. If it has internet access, it can send your code somewhere. Give it scoped, short-lived credentials, keep production secrets out, and review what it pushes. A sandbox limits the blast radius on the machine. It does nothing about the network or the accounts you connect.

How Zydra isolates agents

Zydra gives every desktop its own virtual machine, run by crosvm on our servers, and you reach it with ssh zydra.sh. Agents run inside that VM with Claude Code, Codex and the rest preinstalled, and nothing on your laptop is mounted into it.

On the server side:

Each account's crosvm runs as its own host user, so one account's VM process can't open another's files.
The VM can't reach the host or private networks. Outbound connections to the host's own addresses, loopback and private ranges are refused; the public internet stays open.
Docker and Podman run inside the VM, so an agent that needs containers gets them without access to the host's.
The timeline rewinds the whole machine, disks and memory, to an earlier point if an agent breaks something. It is not a backup, so keep important work in git somewhere else too.

Zydra filters what the VM can send to your terminal and drops everything else, tmux passthrough and links included. Clipboard reads go through your terminal, and Kitty asks before a program reads your clipboard.

The limits: the VM has internet access, so anything you put in it, an API key or a linked GitHub account, the agent can use. The VM runs on our hardware, so you trust us with it, and the disks on the server are not encrypted at rest. If you need the agent on your own machine, coop or a well-built container is the better fit.

Try it

Run ssh zydra.sh in your terminal. The demo is free for 15 minutes and needs no sign-up.