⏱️ Lectura: 8 min
Docker launched Sandboxes, a tool that runs code agents like Claude Code, Codex, or Gemini CLI inside disposable microVMs that isolate each session from the rest of the machine. The promise is straightforward: let the agent work in YOLO mode, without approving every command one by one, without risking the host machine’s filesystem or network.
📑 En este artículo
The tool arrives just as entire teams are already delegating long tasks to autonomous agents and need a real security boundary between “the agent did whatever it wanted” and “the agent broke something in production.”
TL;DR
- Docker launched Sandboxes, a CLI that isolates code agents in disposable microVMs.
- It supports Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, and Kiro out of the box.
- Installation on macOS:
brew trust docker/tap && brew install docker/tap/sbx. - Installation on Windows:
winget install Docker.sbx. - Each sandbox mounts only the project’s workspace; the rest of the host stays invisible.
- Agents can install packages and spin up their own Docker containers inside.
- Docker AI Governance adds network, filesystem, and MCP policies at the organization level.
- It doesn’t require Docker Desktop installed to work.
What happened with Docker Sandboxes
Docker introduced Docker Sandboxes as a dedicated isolation layer for code agents that need to run long tasks without constant human supervision. The core idea is that each agent runs inside a disposable microVM that mounts only the project’s workspace, while the rest of the host system stays invisible to it.
According to the official product page, the list of natively supported agents includes Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, and Kiro. Inside the sandbox, the agent can install packages, modify configuration files, and even spin up its own Docker containers, all without the development team having to approve each step manually.
Installation is deliberately minimal: one command on macOS and another on Windows, with no need to have Docker Desktop running in the background.
Context and history
The problem Docker Sandboxes solves isn’t new: it comes from the tension between speed and security when delegating tasks to an automated process. Traditional containers share the host kernel, which makes them lightweight but also more permeable if a process inside manages to escape isolation. Full virtual machines offer stronger isolation because they virtualize entire hardware, but they take seconds or minutes to boot and consume far more resources.
MicroVMs, popularized in the industry by projects like AWS’s Firecracker, aim for a middle ground: hypervisor-level isolation with boot times close to those of a container. Docker didn’t publicly detail at launch which hypervisor runs under sbx, but the general approach (a dedicated microVM per session, disposable by design) is consistent with that family of technologies.
What changes with Sandboxes is the target audience: it’s not infrastructure for running serverless functions, but an environment designed specifically for a code agent to work with the --dangerously-skip-permissions flag on by default, something most teams had until now avoided outside of a manually configured VM.
Technical details and performance
Each sandbox is a dedicated microVM with the user’s development environment and only the project’s workspace mounted inside it. Nothing else from the host filesystem is exposed to the agent. Network access can also be restricted with custom policies, though applying them centrally across a whole team requires the additional Docker AI Governance layer.
One important detail: agents can run Docker inside the sandbox. An agent that needs to spin up a test database or an auxiliary service can do so with nested containers, without that compromising the real host.
| Option | When to use it | Advantage | Limitation |
|---|---|---|---|
| Docker Sandboxes (microVM) | Running AI agents without constant supervision | Strong isolation, fast boot, disposable | Depends on the sbx CLI; advanced policies require Docker AI Governance |
| Classic containers (Docker Desktop) | Daily development without delegating full control to an agent | Shares the host kernel, minimal overhead | Weaker isolation against a process with broad permissions |
| Traditional VM (VirtualBox/VMware) | Full hardware isolation or multi-OS | Maximum isolation | Slow boot, high resource consumption |
The flow, simplified, is this: the host launches the CLI, the CLI creates the microVM, and inside that microVM the agent runs with broad permissions, including the ability to nest its own containers.
flowchart TD
A["Your host machine"] --> B["sbx CLI"]
B --> C["Sandbox microVM"]
C --> D["AI agent: Claude Code"]
D --> E["Nested Docker container"]
subgraph Isolated
C
D
E
end💡 Tip: run sbx without Docker Desktop installed: the CLI ships its own microVM runtime.
How to start testing Docker Sandboxes
Installing Docker Sandboxes takes a single command depending on your operating system. On macOS:
brew trust docker/tap && brew install docker/tap/sbxThat command adds Docker’s official tap to Homebrew and then installs the sbx binary. On Windows, the equivalent is:
winget install Docker.sbxAt launch, Docker hadn’t published an equivalent package-manager installer for Linux on the official product page; Linux users should check the official documentation for the supported path on their distribution.
Once installed, the general pattern for launching an agent inside a sandbox follows the same logic Docker documents: create the microVM and run the agent’s CLI in permissive mode inside it, for example:
# illustrative pattern, check exact syntax in the official documentation
sbx run -- claude --dangerously-skip-permissionsTo confirm the sandbox actually isolates the agent, the simplest approach is to compare the filesystem visible from inside (only the project’s workspace) against the host’s real filesystem: if the agent can list directories outside its project, the isolation isn’t working as expected.
⚠️ Warning: using --dangerously-skip-permissions outside a sandbox gives your agent full access to your real system: the flag is only safe inside the isolation Sandboxes provides.
Impact and analysis
Docker published testimonials from partners already integrating Sandboxes into their own products. Gavriel Cohen, creator of NanoClaw, summed up the philosophy behind the launch: “you don’t trust agents with security, you build walls around them,” and described Docker Sandboxes as exactly that kind of platform-level isolation infrastructure.
Ben Navetta, engineering lead at Warp, noted that Sandboxes lets agents handle long tasks without compromising security, and that Warp is integrating the tool so agents run with a consistent environment, whether local or in the cloud.
The move fits a broader trend: as more teams run agents autonomously for hours without constant human review, the risk surface of a single process with broad permissions grows. Docker is betting that microVM isolation, faster to spin up than a full VM, becomes the default standard for that kind of workload.
What’s next
For organizations that need more than individual sandbox isolation, Docker offers Docker AI Governance as an additional layer: network access policies for sandbox environments, filesystem access controls and restrictions, and centralized MCP governance across the whole organization, defined once and applied on every developer’s machine.
Docker Sandboxes also doesn’t depend on Docker Desktop to work, which suggests the company is positioning this piece as standalone infrastructure, aimed specifically at teams already working with code agents in production or CI.
📖 Summary on Telegram: View summary
Try it yourself: run brew trust docker/tap && brew install docker/tap/sbx today and launch your first agent in YOLO mode inside an isolated sandbox.
Frequently Asked Questions
What is a sandbox for AI code agents?
It’s an isolated microVM environment that protects your machine’s filesystem and network from whatever the agent does inside. Docker Sandboxes mounts only the project’s workspace: the rest of the disk stays out of the agent’s reach.
What agents does Docker Sandboxes support?
Out of the box, it supports Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, and Kiro. Custom sandboxes can also be defined for other agents.
What does “YOLO mode” mean, and is it safe to use?
YOLO mode means running the agent with the --dangerously-skip-permissions flag, so it doesn’t ask for approval on every action. It’s necessary for the agent to work fast and unsupervised, but it’s risky outside an isolated environment. Sandboxes makes it safe by confining the agent to a dedicated microVM.
How is a sandbox different from a traditional virtual machine?
Sandboxes run fully isolated inside microVMs, providing more isolation than a container without paying the full cost of spinning up a traditional VM. That lets them safely do things that need broader permissions, like running their own Docker containers inside.
What security controls can be configured?
You can define your own network and filesystem policies. To apply them centrally across a whole team (with network access policies, filesystem rules, and MCP governance), there’s Docker AI Governance, built for organizations.
Do I need Docker Desktop to use Sandboxes?
No. Docker Sandboxes works independently, without depending on Docker Desktop being installed on the machine.
References
- Docker Sandboxes: official product page: announcement, interactive demo, and FAQ for the tool.
- Official Docker documentation: complete technical reference for the platform and its CLIs.
- Docker (software) on Wikipedia: historical context on containers and the Docker platform.
- Docker on GitHub: the project’s official repositories and CLI tools.
📱 Enjoy this content? Follow our Telegram channel @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Rubaitul Azad en Unsplash
0 Comments