Docker Sandboxes chooses a microVM boundary over another container

A coding agent that installs packages, rewrites configuration, and launches Docker workloads becomes much less useful if it must stop for approval at every step. Docker Sandboxes approaches the problem from the other direction. Instead of predicting every action the agent may take, it places the whole session in a dedicated microVM and defines filesystem, network, and credential boundaries outside the model. The agent gets latitude inside the box; the host is meant to remain beyond it.

This is not Docker-in-Docker

Each sandbox has its own kernel and a private Docker daemon. When an agent runs docker build, docker run, or docker compose, it does not need the host Docker socket or a privileged container. Images and containers created during a session belong to the daemon inside that microVM. Delete the sandbox and its isolated runtime state disappears with it.

Docker says it built a new virtual-machine monitor rather than using Firecracker. The VMM talks directly to Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows, and KVM on Linux. That cross-platform choice targets the laptops where coding agents actually run. A project workspace can be mounted into the environment, while network access and secret injection are defined before execution. The security boundary is infrastructure, not an instruction in a system prompt that the model is expected to obey.

Isolation still has costs and limits

The product lists support for Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, and Kiro. Inside a sandbox, an agent can install system packages, run services, modify configuration, and create more containers. Docker provides standalone installation paths for macOS and Windows and says Docker Desktop is not required. Central policies for teams, including network, filesystem, and MCP controls, are connected to the separate Docker AI Governance offering.

The HN discussion reached 488 points and 299 comments, with attention centered on the actual boundary rather than the slogan. A Docker employee clarified that every session is a microVM on the operating system's native hypervisor and that the new VMM is not Firecracker. Users praised outbound firewall controls and placeholder-based secret injection, but questioned the login requirement and compared the product with existing VM, Incus, and container-based setups. Others argued that execution isolation should be paired with task-level permissions, read-only roles, approval-gated pull requests, and narrowly scoped credentials.

A microVM therefore does not turn an agent into a trusted actor. It narrows the blast radius while letting the agent use a realistic development environment. Changes to a mounted workspace can still affect the host project, and permissive network or credential policies can still expose valuable systems. The boundary is meaningful, but it does not replace careful policy design. Docker's product page and architecture explanation provide the implementation details.