Contents
In brief
A container is a process with its own view of files, processes, and the network, but it shares the machine kernel. Docker Sandboxes are a separate microVM: their own Linux kernel, filesystem, network, and Docker engine. They are easy to mix up, because the agent inside a sandbox runs containers. The boundary is not the same. Keep the service in a container. Docker's argument is that an agent which installs packages for hours and reads instructions nobody reviewed belongs in a microVM.
What happened
In the Docker blog, Srini Sekaran and Oleg Selajev explain why a sandbox is not "a container with an agent in it." A container isolates an application. Namespaces give it a private view of files and the network. Control groups meter CPU, memory, and disk. Startup is fast, density is high, and Compose, Kubernetes, and nearly every CI system already speak that primitive. If the job is to run a service, execute a snippet, or score something and exit, a container is still the normal choice.
An agent behaves like a person at a laptop, not like a process with a known dependency set. It clones a repository, installs packages, starts PostgreSQL, runs migrations, builds images, reads logs, and tries again for hours. Each step depends on what the previous one left behind. A container is meant to be rebuilt from an image and a few explicit volumes. Whatever the agent created outside those volumes disappears on recreate.
The second difference is where the commands come from. The choice of what to run is probabilistic. Instructions arrive from files, issues, pages, package metadata, and tool output. Some of that input was never reviewed. The post recalls an agent that deleted a production database after misreading its task. With approvals turned off, nothing is left to catch that.
A sandbox starts with sbx run claude. You can stop it and resume it: what the agent installed stays until you remove the sandbox. Inside, the agent has superuser rights and its own Docker, without the host daemon socket.
Why it matters
Escaping a container runs into the shared kernel. Past that are the machine kernel, neighboring processes, and mounted secrets. On macOS and Windows, containers already sit inside the Docker Desktop virtual machine, but they still share that VM's single kernel with each other. A microVM puts a hypervisor between the agent and your kernel. Break out of a container and you land in a disposable guest. The host stays outside. Two agents on one machine cannot see each other's sandboxes. They only reach what you chose to share: the workspace, allowed addresses, MCP servers, and skills.
A separate hole is /var/run/docker.sock. People mount it in Compose, CI, and observability tools, and it hands the container control of the host daemon. The agent does not need a new exploit. Probing the environment is part of the job. In the keynote demo, that was enough for an agent to reach a secrets file on the host. In a sandbox the engine is private, inside the guest. The host socket stays outside.
A rule the agent can read is a rule it can work around. Outbound traffic in this design goes through a host proxy that denies destinations unless someone allows them. For some HTTP services the same proxy injects the credential, so the raw value never enters the virtual machine. The project directory is mounted read-write by default, so the agent can edit and delete files. Clone mode gives it a private copy inside the machine. The original repository stays readable.
In practice
| Reach for a container | Reach for a sandbox |
|---|---|
| You own the code and dependencies, and the run is short | Code is generated or fetched while the session runs |
| It does not need Docker, or CI already provides it | It needs its own Docker with no path to the host socket |
| You want density, Compose, or Kubernetes | You want network and credentials the process cannot switch off |
| A shared kernel is enough | You want a hypervisor between the workload and your kernel |
Docker lists five reasons to start with a sandbox: the agent runs unattended or approvals are automatic; it must build images, Compose, or Testcontainers; it reads issues, pages, package metadata, or MCP output you did not write; keys must not live inside the environment; the session is longer than one task.
The hardware cost is higher than one more container. You need a hypervisor: Apple silicon on macOS 14 or later, Windows Hypervisor Platform, or KVM on supported Ubuntu systems. Inside another virtual machine you need nested virtualization. The cloud option runs the same isolation on Docker's machines. Secrets and network rules stay separate between the local and cloud copies. Tool kits and sbxenv.yaml are marked early access and experimental. A teammate can recreate the sandbox with one command, but the format can still change.
Takeaway
A container isolates an application that behaves the way it was built. An agent needs a boundary the model cannot rewrite, and state that outlives a single process. Keep packaging the application as a container. If the agent reaches the network and installs packages on its own, put the agent in a microVM.
Comments