Docker Sandboxes for AI Agents

Docker Sandboxes Release Details

Docker announced Docker Sandboxes, a product that supplies disposable microVMs for running AI coding agents. The release targets tools including Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, and Kiro. Agents receive a full development environment with the project workspace mounted, while the host system remains isolated. Installation commands were published for macOS via Homebrew and for Windows via winget. The announcement appeared on the Docker site and was discussed on Hacker News.

MicroVM Isolation and Controls

Each sandbox runs inside a dedicated microVM. This boundary prevents the agent from accessing host files, credentials, or network resources outside the defined limits. Agents can still install packages, edit configuration files, start services, and launch their own Docker containers inside the sandbox. Network and filesystem rules are set at creation time and can be enforced across an organization through Docker AI Governance features. The microVM starts faster than a traditional virtual machine and is discarded after use with a single command.

Filesystem restrictions mount only the selected project directory. Network controls block or allow outbound connections according to policy. Credential isolation keeps host secrets out of the agent environment. These settings replace the need for manual permission prompts or constant supervision when an agent operates in default-dangerously-skip-permissions mode.

Running Agents Inside Sandboxes

Agents such as Claude Code or Gemini CLI receive the same shell and tooling they would have on a developer machine. The difference is that any destructive action stays contained. An agent can execute long-running build or test commands, spin up supporting containers, and modify code without requiring the user to review every step. When the task finishes, the sandbox is removed and the next run starts from a clean state.

Setup on macOS uses the provided Homebrew tap. On Windows the winget package installs the binary directly. After installation the sbx command creates a new environment, mounts the current directory, and hands control to the chosen agent. Documentation lists the exact flags for custom network rules and volume mounts.

Practical Tradeoffs

The main advantage is reduced risk when agents run unattended. Teams can enable broader autonomy without exposing the workstation or CI host. The main cost is the added layer between the agent and the host resources. Some operations that rely on direct hardware access or specific kernel modules may behave differently inside the microVM. Resource usage is higher than a plain process because each sandbox carries its own kernel and runtime. For short, low-risk tasks the overhead may exceed the benefit.

Docker Sandboxes does not replace existing permission systems or code review processes. It adds an execution boundary that makes permissive agent modes safer to use by default.

FAQs

How does Docker Sandboxes differ from running an agent directly on the host?
It places the agent inside a microVM with explicit filesystem and network limits, so actions cannot affect the host even if the agent runs with full permissions inside the sandbox.

Can agents still use Docker inside the sandbox?
Yes. The sandbox provides a complete environment where agents can start containers, build images, and run services without touching the host Docker daemon.

What happens to data after a sandbox is destroyed?
The microVM and all mounted state are discarded. Only changes written back to the host workspace through the explicit mount persist.

Need a consultation?

I help companies and startups build software, automate workflows, and integrate AI. Let's talk.

Get in touch