Docker Sandboxes vs. Containers: Key Differences | Docker

Secure, minimal container images for every team, free with enterprise features, if needed.
If you’ve used Docker for a while, “Docker Sandboxes” might read as “a container with an AI agent inside.” Containers have been the unit of nearly everything Docker ships for over a decade, and a sandbox might sound like one more way to package a workload.
They’re actually different technologies. A container is an isolated process that shares the host kernel with everything else on the machine. Docker Sandboxes are dedicated microVMs with their own Linux kernel, filesystem, network, and Docker Engine, built for autonomous coding agents that need a whole development machine to work in. A sandbox can run containers, which is part of why the two are easy to conflate.
In his WeAreDevelopers keynote, Docker President Mark Cavage said containers are doing exactly the job they were designed to do, but we’re asking them to do a different job.
Containers were built to isolate applications, which they still do well. But a coding agent is an actor: it makes decisions and operates on your systems the way a developer uses a laptop. It clones repositories, installs packages, starts databases, builds images, and tries again for hours. It can also act on instructions from files, web pages, and tool output that nobody reviewed.
That different job needs a different boundary, and where that boundary sits determines how far an agent’s mistake can travel. This post covers how Docker Sandboxes and containers isolate workloads, what changes beyond the kernel, what a sandbox costs you in setup, and how to pick.
A container is a process, or a group of processes, running on the host with its own view of the filesystem, process tree, and network. Linux namespaces provide that view, and cgroups meter CPU, memory, and I/O. Every container on the machine also shares the host kernel, which is why containers start quickly, pack densely, and carry so little overhead.
This design has more than a decade of tooling behind it. Compose, Kubernetes, OCI registries, image scanners, and nearly every CI system treat the container as the common primitive. If the job is to run a service, execute a code snippet, process one request, or run an evaluation and disappear, a container is usually the obvious pick, and it will stay that way.
ⓘ Containers share one kernel, even inside a VM. On macOS and Windows, Docker Desktop runs your Linux containers inside a virtual machine, which keeps them off your host operating system. Every container in that VM still shares its single kernel, so the isolation between one container and the next is unchanged.
Docker Sandboxes run an AI coding agent inside a microVM that has its own Linux kernel, its own filesystem and network stack, and a private Docker Engine. The agent gets sudo inside the isolated environment. It can install packages, run services, build images, and bring up an entire Compose application without reaching the host Docker daemon, the host filesystem outside its workspace, or other sandboxes on the same machine.
Getting one running takes a single command, using sbx, the Docker Sandboxes CLI:
That creates the sandbox and starts the agent. You can stop it, resume it, and come back to everything the agent installed until you remove the sandbox.
Coding agents need a full machine because their sessions build up state over hours and they act on unvetted instructions. A container is built for a process with a known set of dependencies, and an agent’s work doesn’t fit that shape.
An agent needs the authority of a whole machine and a boundary designed for one. The capabilities that make an agent useful, such as running code, installing packages, and reaching the network, are the same ones that wear at the walls around it. An agent probes the edges of its environment because the job requires changing that environment.
A coding agent’s session looks like a developer’s afternoon. It clones a repository, installs packages, starts PostgreSQL, runs migrations, builds images, launches the app with Compose, reads the logs, changes the code, and tries again. That loop can run for hours, and each step depends on what the previous one left behind.
A container is designed to be rebuilt from an image and a few explicit volumes. The packages, databases, and build output an agent creates outside those volumes are lost when the container is recreated. That’s less than ideal for a session where every step builds on the last.
Box by ASCII describes this distinction neatly: “It uses the sandbox the way a developer uses a laptop, so the sandbox has to behave like one.”
The program deciding which command to run is probabilistic, and it can read instructions from many places at once, including source files, issue descriptions, web pages, package metadata, and MCP tool output. Some of that input is untrusted, and a malicious instruction planted in a README or a tool description can steer the agent on purpose. The code it generates may also be wrong or actively hostile.
We’ve already seen an agent that deleted a production database after misreading its task. Once the agent is running unattended in YOLO mode, there’s no permission prompt left to catch it. A workload with that much authority and that little predictability needs a boundary designed for it.
Put these facts together and you get the reason why we built Docker Sandboxes. An autonomous coding agent needs machine-shaped capabilities without access to everything on the developer’s machine, which comes down to four things:
The next sections show what each looks like, starting with containment.
The short version is that a container’s boundary is the host kernel it shares, and Docker Sandboxes have a hypervisor boundary around a kernel the agent has to itself. That one difference decides how far a compromise can travel, and it also settles the awkward question of how an agent could get access to Docker.
This is where containers and containment part ways. A container can b