Summary: Docker made Sandboxes generally available to give AI coding agents disposable microVMs with separate daemons, filesystems, and networks. The tool supports agents including Claude Code and Codex, runs without Docker Desktop, and offers a free CLI with paid centralized governance. It reduces the blast radius of unattended installs, tests, and container builds while leaving policy decisions to teams.
There is an awkward tension at the heart of AI coding agents: to be useful, they need full permission to edit files, install packages, and run commands; to be safe, none of those permissions should be handed out casually. Docker’s answer was to turn it into a product. Sandboxes is now generally available, using disposable microVMs to wall off a safe zone for agents such as Claude Code and Codex. The company’s positioning fits in one line: “disposable, isolated sandboxes for AI agents that need safe, unattended execution.”
The launch thread piled up hundreds of points on Hacker News, and that attention points to a real shift: agents are graduating from tools that give advice into colleagues that take action. What holds developers back is no longer what the model can do — it is whether they are willing to let the agent run loose.
The Sticking Point: The Permission Paradox
An agent only earns its keep by doing the real work: installing dependencies, editing config files, starting local services, running tests. Doing all of it straight on a developer machine amounts to handing over every corner of the host, so plenty of users simply flip on “YOLO mode” and wave through every permission prompt. Docker’s product page is blunt about the framing: the question is not whether to skip permissions, but how big the blast radius gets once you do.
The audience Docker names — agents that need “safe, unattended execution” — is the overnight-job case: hand over a task, let the agent install dependencies and run the test suite, then come back to a diff. That is exactly the situation in which nobody is around to watch the prompts.
How It Works: One microVM for Each Agent
Isolation happens at the microVM level. Every sandbox carries its own Docker daemon, filesystem, and network; only the project workspace gets mounted in from the host, with a “hard security boundary” between the two. Once inside, an agent may install packages, change settings, or even spin up containers of its own — and none of it reaches the rest of the host. That last ability counts for more than it sounds like: agents that build and test containerized apps need to run Docker themselves, and Sandboxes lets them do so without handing over the host daemon. Filesystem, network, and credentials can each be governed by their own policy.
The supported roster spans Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, and Kiro, with custom agents allowed as well.
Up and Running in Three Commands
Installation reaches all three major platforms: brew on macOS, winget on Windows, apt on Ubuntu. After signing in, run sbx run claude from a project directory and the agent comes up inside its sandbox. One detail stands out: Docker Desktop is not required — a clear nod to CI and server use cases. Advanced configuration covers credentials management, declarative project environments, GPU passthrough, and an upstream proxy, and Docker tracks releases and feedback in a public sbx-releases repository.
The Money Side: Free CLI, Paid Governance
Individual use costs nothing at all, commercial use included. What carries a price is organizational governance: through Docker AI Governance, admins can enforce sandbox network, filesystem, and MCP policies centrally across every developer machine in an organization. That split is a smart one — individual developers adopt with zero friction, and once the habit takes hold, enterprise governance becomes the natural point of conversion.
What This Means for AI Coding Workflows
Two signals stand out. First, sandboxes are shifting from “build your own” to “ship with the desktop”: Warp is integrating Sandboxes, and its engineering lead Ben Navetta says the goal is letting developers “run agents freely with a consistent environment,” while NanoClaw creator Gavriel Cohen calls it the answer “at the infrastructure level.” Second, the risk model for unattended execution has changed: once the blast radius contracts from “your machine” to “one disposable VM,” letting an agent grind through long tasks overnight becomes far easier to accept. For product teams the question is no longer “should agents get a sandbox” but “what does your sandbox policy look like.”
There is a quieter strategic read as well. A CLI that sits alongside the Docker tooling a team already has turns adoption into a configuration change rather than a decision to take on a new runtime — and for teams already living in containers, that is the easiest kind of infrastructure shift: the one that arrives inside a tool they already run every day.