What is Docker Sandboxes (sbx)?
Docker Inc. ships Docker Sandboxes as a standalone CLI called sbx, which launches an AI coding agent (Claude Code, Codex, GitHub Copilot, Gemini CLI, OpenCode, or Cursor) inside a microVM with its own kernel and its own Docker Engine. On Claude Code, sbx defaults to launching claude --dangerously-skip-permissions, the flag that removes confirmation prompts before every action the agent takes.
Docker ships 12 image variants under docker/sandbox-templates:*, all based on Ubuntu, with a non-root agent user that has sudo. The -docker variants bundle a full Docker Engine inside the microVM, backed by a 10 GB sparse volume: the agent container runs in privileged mode there to host that engine, but only inside the microVM.
What does microVM isolation guarantee, and what doesn't it cover?
Separating the kernel and Docker Engine stops an agent from acting directly on the host machine. Two areas stay outside this isolation boundary: MCP servers (Model Context Protocol, the standard that lets an AI agent call external tools) that communicate locally over stdio still run on the host, and the skills store shared across sandboxes is mounted read-write. One more thing to watch: sbx template save captures the entire filesystem, secrets included. For configuration, ~/.claude isn't imported and symlinks pointing to the host aren't followed; sbx skills import pulls in skills explicitly.
How is network access controlled inside a sandbox?
For networking, sbx blocks UDP and ICMP (used by diagnostic tools like ping), with no policy option to unblock them. Non-HTTP TCP traffic, like SSH, can still be allowed through a rule such as myhost:22. Three network presets are available: Open, Balanced, and Locked Down.
Do API keys and credentials enter the sandbox?
SSH agent forwarding (the mechanism that lets you use a local private key without copying it into the remote environment) is enabled by default: the key never leaves the host. A host-side proxy injects supported secrets as an HTTP header; the sandbox sees only a proxy-managed sentinel value. For everything else, sbx secret set-custom declares a domain-and-variable pair.
Which systems does sbx run on?
| System | Requirements |
|---|---|
| macOS | macOS 14 or later, Apple Silicon chip |
| Windows | Windows 11, Hypervisor Platform enabled |
| Linux | Ubuntu 24.04 or later, KVM, user in the kvm group |
You'll need a Docker account. CLI telemetry, enabled by default, can be turned off with SBX_NO_TELEMETRY=1; agent prompts and code are excluded from it.
Which releases have shaped sbx since July 2026?
| Version | Date | Key change |
|---|---|---|
| 0.35.0 | July 10, 2026 | Host environment variables no longer used for authentication; sbx policy overhaul; SOCKS5 transport |
| 0.37.0 | July 24, 2026 | SSH access to sandboxes (experimental); shared skills |
| 0.37.1 | July 29, 2026 | SSH no longer forwards the ANTHROPIC_API_KEY, OPENAI_API_KEY, and GH_TOKEN keys by default |
| 0.38.0 | August 6, 2026 | Spec kit v2; first-class MCP management via a built-in gateway; --deny-network option; fix for CVE-2026-17106 |
CVE-2026-17106 (Common Vulnerabilities and Exposures, the public registry of software security flaws) affected the copy-out direction of sbx cp, the sandbox-to-host side of the file-copy command: a destination-escape vulnerability, fixed in 0.38.0.
Our take
This summary is based on the official documentation and the release history, without running the CLI ourselves. In our view, moving the isolation boundary to the hypervisor level makes a real difference for anyone running agents with confirmations turned off: a compromised agent stays locked inside its own kernel, not in a namespace shared with the host. That's no excuse to skip the exceptions, though: MCP over stdio still runs on the host, the skills store is shared read-write, and even template save bundles up secrets when it captures a snapshot.
