AIArticle
Its new microVM Sandboxes make YOLO-mode coding agents safe by default, with a custom hypervisor instead of containers.
There's a quiet admission buried in Docker's newest product, and it's a big one: containers were never a security boundary you should bet your laptop on. Docker Sandboxes — the company's disposable, isolated environments for AI coding agents, which hit the Hacker News front page this week — doesn't isolate agents with containers at all. It puts each one in a microVM with its own kernel. When the company whose name is synonymous with containers ships a hypervisor to solve the untrusted-code problem, that tells you something about where the container security story actually ends.
It's the right call, and after digging through the architecture and the early field reports, I think Sandboxes is the most credible answer yet to a problem every agent user has: you want to run Claude Code or Codex with permissions off, and you'd rather not bet your home directory on it.
The permission-prompt economy is collapsing #
The dirty secret of coding agents is that almost everyone eventually runs them in bypass mode. Claude Code's --dangerously-skip-permissions
flag exists because approving every file write and shell command turns an autonomous agent into a very slow pair programmer. But bypass mode on your host means one hallucinated rm -rf
, one exfiltrated .env
, one poisoned dependency running a postinstall script, and the blast radius is your entire machine.
Docker's answer is to make bypass mode the default — the product page literally leans into "YOLO mode" — and move the safety boundary from the agent's judgment to the infrastructure. Filesystem access, network policy, and credentials are decided before the agent boots, not negotiated prompt-by-prompt while it runs. That's the correct architecture. Permission prompts are a consent mechanism, not a security mechanism; anyone who's absent-mindedly hammered "yes" through twenty of them knows the difference.
Why not containers? Ask Docker #
The technically interesting part is what Docker built underneath. Containers share the host kernel, so a kernel exploit is a full escape. Worse for this use case: coding agents want Docker itself — spinning up Postgres for tests, running docker compose
— and Docker-in-Docker traditionally means mounting the host socket or running privileged, which hands the agent the keys you were trying to hide.
Sandboxes sidesteps both. Each sandbox is a microVM with its own kernel and its own private Docker daemon inside the VM. The agent gets real docker build
, docker run
, and docker compose
with no socket mounting and no host privileges. That nested-daemon design is, to my knowledge, the first mainstream local product to get agent Docker access right, and it's the feature that separates this from every devcontainer-shaped workaround.
Notably, Docker didn't reach for Firecracker, the microVM standard powering AWS Lambda and most cloud sandbox startups. Firecracker is Linux/KVM-only, and Docker's users live on Macs and Windows machines. So they built their own VMM that sits on each OS's native hypervisor — Hypervisor.framework on macOS, Windows Hypervisor Platform, KVM on Linux. One codebase, three platforms, no translation layer. That's a real moat: cloud sandbox vendors like E2B can't easily follow you onto a MacBook.
What using it actually looks like #
The workflow is refreshingly small. Install the sbx
CLI (brew install docker/tap/sbx
on macOS, winget install Docker.sbx
on Windows; Ubuntu needs KVM group membership) — no Docker Desktop required — then:
sbx run claude # Claude Code in a fresh microVM
sbx run claude --branch my-feature # work lands in a git worktree under .sbx/
Only your project workspace is mounted in. The branch mode is smart: the agent's changes accumulate on a worktree, so you review a diff instead of discovering what it did to your working tree. Sandbox Kits — YAML specs declaring tools, env vars, injected credentials, and allowed network domains — make environments reproducible via a --kit
flag. Claude Code, Codex, Gemini CLI, Copilot CLI, Kiro, and OpenCode are supported, and the CLI is free, including for commercial use. The business model is the classic Docker play: the tool is free, and org-wide policy enforcement gets upsold as Docker AI Governance.
The rough edges are real #
This shipped as GA in late January 2026 after an experimental preview, and it shows. The most thorough independent review I found — .NET veteran Andrew Lock, running it on Windows — praised the experience of unattended agents but called the performance overhead on his projects "crippling," and ultimately switched the network policy from "balanced" to open because the default was too restrictive to get work done. Which undercuts the point: an isolation product whose usable configuration is "allow everything" is only isolating the filesystem. GitHub discussions echo the pattern — kit network policies misbehaving, a secrets API that users describe as janky, no clean story for SSH-agent-backed commit signing.
None of this is disqualifying. It's the normal texture of a v1, and the core boundary — the microVM — is sound. But go in expecting to tune, not to set-and-forget.
Where this leaves everyone else #
The agent-sandbox space had split into two camps: cloud microVMs (E2B, Modal, Daytona — great for products, wrong for local dev loops with big node_modules trees) and local OS-level sandboxing, like Anthropic's own sandboxing for Claude Code built on seatbelt and bubblewrap — lighter weight, but a syscall-filter boundary rather than a hardware one. Docker just planted a flag in the unclaimed middle: local, hardware-isolated, Docker-native, free.
The losers are the duct-tape solutions. If you've been running agents in a devcontainer and calling it isolation, the vendor of the underlying technology has now told you, in architecture-blog detail, why that boundary doesn't hold against an adversarial workload. And cloud sandbox startups just watched the company with the largest developer-tools distribution channel on earth give away their local equivalent.
My verdict: this is a genuine shift, not a feature-release press cycle. The threat model is right, the architecture is right, and the default — isolation instead of interrogation — is what agent tooling should have shipped with from the start. Wait a quarter if flaky network policies would burn you today. But if you're running coding agents in bypass mode on bare metal in mid-2026, you're now doing it without an excuse.
Sources & further reading #
Docker Sandboxes - Disposable, isolated sandboxes for AI agents— docker.com - Docker Sandboxes: Run Claude Code and Other Coding Agents Unsupervised, but Safely— docker.com - Why MicroVMs: The Architecture Behind Docker Sandboxes— docker.com - Docker Sandboxes documentation— docs.docker.com - Running AI agents safely in a microVM using docker sandbox— andrewlock.net - Docker Sandboxes and microVMs, explained— infoworld.com - Docker Sandboxes - Disposable, isolated sandboxes for AI agents— news.ycombinator.com
Rachel Goldstein· Dev Tools Editor
Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop.
Discussion 0 #
No comments yet
Be the first to weigh in.