← Back to research
·7 min read·company

Docker Sandboxes

Docker Sandboxes runs coding agents in local microVMs with a private Docker daemon, workspace modes, and credential proxy. The sbx CLI is free; organization governance is paid.

https://www.docker.com/products/docker-sandboxes/ ↗
coding-agentsenterpriseself-hosteddockermcp

Key takeaways

  • Each sandbox has its own Linux kernel and Docker daemon; installing the sbx CLI does not require Docker Desktop or a host Docker Engine.
  • Direct mode edits host files immediately; clone mode separates writes but still exposes the source repository, including ignored secrets, for reading.
  • Proxy-managed credentials stay outside the VM, but explicit environment secrets and OAuth passthrough can bypass that protection.
  • The local CLI is free for commercial use with Docker sign-in; centrally managed organization policies require a separate paid subscription.

FAQ

Is Docker Sandboxes just a Docker container?

No. Each sandbox runs a Linux microVM with its own kernel and Docker Engine, using the host operating system's hypervisor.

Which operating systems are supported?

The installation guide lists Apple silicon macOS 14+, x86-64 Windows 11 with Windows Hypervisor Platform, and Ubuntu 24.04+ on x86-64 or Arm64 with KVM. Other Linux artifacts do not imply tested distribution support.

Does clone mode hide secrets in my repository?

No. It mounts the source repository read-only, including ignored and untracked files. It protects against writes through that mount, not reading a .env file already present there.

How much does Docker Sandboxes cost?

The sbx CLI is free for personal and commercial work after Docker sign-in. Organization governance is separately priced through sales; agent subscriptions and model usage remain separate.

Executive Summary

Docker Sandboxes packages local microVMs for coding agents. Its sbx CLI gives each environment a Linux kernel, private Docker Engine, persistent disk, and host-side network controls. It is a different execution boundary from giving an ordinary container access to the host Docker socket.[1][2]

The important choice is how much authority crosses that boundary: shared files, permitted destinations, brokered credentials, and host integrations. A VM does not make the files deliberately shared with it immutable, or the API operations authorized through it harmless.[3]

AttributeVerified September 15, 2026
ProviderDocker, Inc.[4]
Current releasesbx v0.43.0, published September 15, 2026[5]
macOSApple silicon, macOS 14 or later[6]
WindowsWindows 11, x86-64, Windows Hypervisor Platform[6]
LinuxUbuntu 24.04+, x86-64 or Arm64, KVM; nested virtualization needed inside a VM[6]
Host dependencyNeither Docker Desktop nor Docker Engine is required[6]

See the local agent sandbox comparison for alternatives.

Product Overview

Supported agents include Claude Code, Codex, Cursor, Gemini, OpenCode, and others, plus an agent-free shell. Custom kits and templates configure reusable environments. The v0.43.0 release restores shorthand launches for Kiro, Copilot, and Droid after their migration to public kits.[7][5]

Workspace modeWhat the agent receives
DirectA live read-write host directory; sbx run defaults to the current directory
CloneA read-only source repository plus a private working clone inside the VM
MountlessNo host workspace when the path is omitted from sbx create

Files installed inside the VM survive stops and restarts until the sandbox is removed. Direct-mounted files remain on the host. Each VM maintains its own image cache and Docker state, which consumes local storage.[8]

A documented mountless workflow is:

sbx create --name scratch claude
sbx run --name scratch

A mountless workspace can still have separately configured shared resources, such as the agent skills store. These commands were reviewed, not executed for this report.[2]

Technical Architecture

Docker describes a purpose-built VMM using Hypervisor.framework on macOS, Windows Hypervisor Platform, and KVM on Linux. Its performance claims are vendor claims; this review did not benchmark startup or filesystem performance.[9]

The Docker daemon runs inside each VM. Outbound TCP follows a host proxy; both its transparent and HTTP forward paths enforce destination policy, but credential injection occurs on the forward path. Direct external UDP and ICMP are blocked. DNS resolution is policy-aware.[8][10]

Default-deny networking does not mean an empty allowlist. Docker warns that shipped rules include broad wildcards, including *.googleapis.com. Inspect the actual active rules before treating them as a narrow model-only policy.[3]

Proxy-managed credentials are represented by placeholders in the sandbox and substituted on the host. This depends on the credential mechanism: kits can explicitly enable OAuth passthrough, which sends real tokens into the VM, and directly supplied secrets can also be exposed. Secret availability is global by default unless scoped to a sandbox. On headless Linux, missing keychain support can cause storage to fall back to a file protected by filesystem permissions.[11]

Strengths

  • Docker workloads remain inside the VM. The agent can build images and run Compose without using the host daemon.[2]
  • Workspace authority is explicit. Direct, clone, and mountless modes support different review and persistence workflows.[8]
  • Host-side credential management reduces raw-key exposure. The normal proxy path can authorize requests without handing the credential to the agent.[11]
  • One product covers three host platforms. The documented support matrix includes native Windows and Ubuntu, as well as Apple silicon Macs.[6]

Cautions

  • Read-only is not secret-free. Clone mode exposes ignored and untracked files under the source repository, including .env. Direct mode can also change Git hooks and build scripts that later execute on the host; Git hooks do not appear in a normal diff.[2]
  • Shared integrations extend trust. A writable skills store can affect other sandboxes using it. Local stdio MCP servers run on the host, outside the VM boundary.[3]
  • Agent approval prompts are normally skipped. Docker documents changing the permission mode or a custom kit to restore them; permitted external actions still deserve deliberate policy.[12]
  • Authentication affects automation. Docker sign-in is required. Expired sessions can interrupt noninteractive runs until reauthentication.[12][13]
  • Local resources and compatibility matter. Large direct-mounted repositories can be slow. Linux package availability beyond Ubuntu does not establish official distribution support.[13][6]

What Developers Say

In the August 10, 2026 Hacker News discussion, rusch described daily use and valued the firewall and placeholder credentials, while finding login annoying. Humphrey reported useful concurrent short-lived sandboxes but criticized authentication interruptions and preferred a worktree workflow. These are individual experiences with then-current versions, not reliability measurements of v0.43.0.[14]

A May/June GitHub report by yoshinoriishii documented headless Ubuntu credential failures with v0.31.1 and a working manual keyring setup. Current documentation now describes an automatic file-store fallback. The old issue remains useful history, but its open status alone does not establish that current releases have the same blocker.[15][12]

Pricing & Licensing

OfferingPublic terms checked September 15, 2026
Local sbx CLIFree, including commercial and professional use; Docker account sign-in required
Organization governanceSeparate paid subscription through Docker Sales; centralized network, filesystem, and MCP policy, sign-in enforcement, and audit logs
[12]

The public releases repository carries an all-rights-reserved notice rather than an open-source license. Free usage should not be confused with permission to fork the runtime. Local hardware, storage, and agent/model-provider charges are separate from the CLI price.[4][8][7]

Competitive Positioning

The decision is between a separate local Linux environment and restricting a process that uses the existing host environment. Compare OpenShell, nono, and Anthropic Sandbox Runtime in the local comparison, using actual host support and policy defaults rather than the sandbox label.

Disclosure: Ry Walker is CEO of Tembo. Tembo is relevant when the requirement expands to running coding agents in managed or self-hosted cloud environments with shared sessions, integrations, and review workflows. Docker Sandboxes addresses the local execution environment; this is a difference in deployment and product scope, not evidence of an integration.[16]

Ideal Customer Profile

Best fit: developers who need local agents to install packages or build containers while keeping a separate Linux runtime and choosing which host resources are shared.

Poor fit: teams requiring an open-source runtime, unsupported host hardware, or a workflow that assumes no vendor login.

Viability Assessment

Docker publishes frequent releases with concrete fixes. June's v0.33.0 closed a DNS policy bypass and ICMP egress issue; September's v0.43.0 includes credential-consent and kit-trust fixes. That is evidence of maintenance, not proof that the current runtime has no security defects.[17][5]

The public evidence reviewed here does not establish an active-user total specific to Sandboxes. Docker's broader popularity should not be substituted for product-specific adoption.

Bottom Line

Docker Sandboxes is a practical candidate for local coding workflows needing a separate kernel and private Docker Engine. Evaluate the chosen workspace mode, active network rules, credential bindings, and host integrations as part of the boundary.

Recommended for: local agent development that benefits from a reusable Linux VM.

Not recommended for: assuming shared files, permitted APIs, or host MCP tools become harmless because execution starts inside a microVM.

Outlook: validate repository performance and authentication behavior with the current release before broad rollout.

Research by Ry Walker Research • methodology

Sources

Share on XShare on LinkedIn