News · 2026-08-10

Docker gives every coding agent its own microVM

Docker has launched Sandboxes, a tool that runs AI coding agents inside disposable virtual machines with their own kernel, filesystem, network, and private Docker engine. The command-line tool, sbx, is free including for commercial use, and it supports Claude Code, Codex, Copilot, Cursor, Gemini, and half a dozen other agents on macOS, Windows, and Linux. It arrives four days before Anthropic makes unsupervised operation the default for new Claude Code sessions.

Key facts

• Each sandbox gets its own microVM boundary, not a shared kernel -- including its own Docker daemon inside the sandbox.
• The sbx CLI is free, commercial use included; only organization governance is a paid add-on.
• Supported agents include Claude Code, Codex, Copilot, Cursor, Droid, Gemini, Kiro, OpenCode, Docker Agent, and a plain shell.
• Primary source: Docker's launch post and the Sandboxes documentation.

The problem this solves is specific and, until recently, mostly theoretical. An AI coding agent that can run shell commands can do everything you can do: delete files, read credentials from your environment, push to remote repositories, install packages, make network calls. As long as a human approved each command, that was manageable. As agents move toward running unattended for hours, it stops being manageable, because nobody is reading the commands anymore.

The usual answer was a container. Docker's own architecture documentation argues that a container is the wrong shape for this, and explains why by comparing the two workarounds developers actually use. One is mounting the host's Docker socket into the container, which hands the agent control of the host's Docker engine -- an escape hatch, not a boundary. The other is Docker-in-Docker, which is awkward and fragile. Sandboxes instead uses a microVM: a lightweight virtual machine with its own kernel. The analogy is the difference between giving a contractor a locked room in your house and giving them a trailer parked outside. The room shares your plumbing and wiring. The trailer does not.

Because each sandbox carries a private Docker Engine, an agent inside it can build and run its own containers without ever touching the host daemon. That is the concrete thing developers were previously hacking around, and it is why Docker frames this as the answer to the Docker-in-Docker problem rather than as another container flavor.

The security model has real, documented limits, which is a good sign rather than a bad one. Sandboxes are network-isolated. Raw TCP, UDP, and ICMP traffic is blocked. The host-side proxy only permits HTTP and HTTPS to allowed domains, and proxy auto-configuration files are not supported. An agent that wants to exfiltrate something has a narrow, logged, domain-restricted path rather than a socket.

Community reception on Hacker News was strong and practical rather than ideological: the thread drew 627 points and 349 comments, with users asking for performance numbers, complaining about login friction and documentation quirks, and several saying it was already useful in daily work. Docker is not alone in the space. exe.dev attacks the same problem from the other direction, giving agents persistent Linux virtual machines with root, SSH, a public hostname, a real network stack, and secrets injected by a host-side proxy -- more "real computer" than "disposable container," with per-second and pooled pricing.

The timing is the part worth sitting with. Anthropic's permission-modes documentation says that starting August 14, 2026, auto mode becomes the default permission mode for new Claude Code sessions on Pro, Max, and Team plans -- a change we covered in Claude Code stops asking permission on August 14. Anthropic has been careful about the blast radius there too: from version 2.1.142, a repository cannot grant itself auto mode through its own checked-in settings file, which closes an obvious path for a malicious repo to escalate its own privileges. That is a supply-chain consideration, not a convenience one.

The honest caveat is in the default. Docker's usage docs say direct mode -- the default -- mounts your host source tree read-write, so edits show up instantly. That is what most people want, and it also means the isolation you actually get depends on whether you passed the --clone flag. The kernel boundary protects your machine; it does not protect the directory you deliberately handed over. And no sandbox addresses the other half of the agent risk surface: a sandboxed agent that reads a poisoned web page can still be talked into doing the wrong thing inside its own walls, which is why prompt injection and sandboxing are separate problems that need separate answers.

Primary source, verified: read the paper →

Ground Truth. (2026, August 10). Docker gives every coding agent its own microVM. Ground Truth. https://groundtruth.day/news/docker-gives-every-coding-agent-its-own-microvm.html

@misc{groundtruth:docker-gives-every-coding-agent-its-own-microvm,
  title  = {Docker gives every coding agent its own microVM},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {aug},
  url    = {https://groundtruth.day/news/docker-gives-every-coding-agent-its-own-microvm.html}
}

Topics: cybersecurity · ai-security · sandboxing · agents · supply-chain · developer-tools