Docker sbx: What a Sandboxed Coding Agent Can Still Delete

Start Claude Code inside Docker's new sandbox and it launches with claude --dangerously-skip-permissions as the standard startup command. That is the point, not an oversight — and it is also the reason the boundary is worth reading carefully before you let an agent run unattended.

Docker Sandboxes is Docker's tool for running AI coding agents inside an isolated microVM on your own machine, managed by a standalone CLI called sbx. A recent dev.to walkthrough works through the docs and the setup; the summary below is what it establishes about what actually crosses the trust boundary.

Full autonomy is the default, by design

The official tutorial, as quoted in the walkthrough, says the built-in sandbox integrations start agents "in their full-autonomy mode," and that you do not need to add those flags yourself. Every agent has its own version of the flag: Codex bypasses approvals, while Cursor, Copilot and Gemini use what their vendors call YOLO mode.

Docker's launch post for the microVM release puts the trade plainly: "Since they can't harm your computer, let them run free" (Docker blog, January 2026). Whether that holds depends entirely on what you mounted.

Why a container stopped being enough

Two container-era assumptions break with coding agents. Containers share the host kernel, so namespaces and cgroups give a kernel-level boundary rather than a hardware-level one; a microVM boots its own kernel under a hypervisor instead. Docker describes that microVM as the primary trust boundary in its security model — the agent has full control inside, including sudo, and the VM edge is what stops it reaching anything else.

The second problem is the Docker socket. An agent that can build containers wants host Docker access, and a tool with host Docker access effectively has root on the host, because docker run -v /:/host is always available. Each sandbox runs a private Docker daemon inside the VM, so the agent builds, pulls and runs containers with no access to your host daemon. The author notes Docker claims this is unique among sandboxing options, and that they found no counterexample.

What crosses in, back, and never

Into the VM: your workspace directory, credentials — but only as injected headers — outbound TCP to allowed destinations, and a shared skills store mounted read-only by default. The credential design is the clever part: a host-side proxy injects authentication headers into outbound requests, and the raw credential values never enter the VM. The agent uses your GitHub or Anthropic auth without ever holding the token.

Back to the host: workspace file changes, outbound connections you allowed, and skill store writes only if you flipped that mount to read-write.

Never: your host filesystem outside the workspace and skills store, your host Docker daemon, and your host network interfaces directly. Sandboxes cannot talk to each other over the network, outbound UDP is blocked unless you enable an experimental flag, and ICMP is blocked outright.

Then the caveat that matters most. A direct mount is read-write. Your project directory is the exception to the sandbox boundary, and the agent can modify or delete its files. The walkthrough cites Andrew Lock's hands-on writeup reaching the same conclusion — the sandbox only has access to your working directory, "so yes, it could delete your git repo," and that is roughly the extent of the damage. Keep the work under version control, use --clone, or both.

Setup, and the five commands that matter

The CLI installs standalone and does not require Docker Desktop or Docker Engine on the host. macOS uses Homebrew (brew install docker/tap/sbx), Windows uses winget install -h Docker.sbx, and Ubuntu installs the docker-sbx package from Docker's apt repository. Then sbx login, and from a project directory sbx run --name my-sandbox claude. The first run pulls the agent template docker/sandbox-templates:claude-code.

From a second terminal, sbx ls shows a workspace column — that column is the entire filesystem the agent can see of your machine. sbx exec -it my-sandbox bash drops you into the VM. sbx stop pauses and preserves state across restarts; sbx rm deletes the sandbox.

Network policy is the real security posture

Preset	Outbound traffic	Model provider API	Good for
Open	Everything allowed	Allowed	Trusted tasks on machines with nothing to protect
Balanced	Denied by default, common dev sites allowed	Allowed	Daily development; the docs' recommended start
Locked Down	Everything blocked	Blocked until allowed	Untrusted or unattended tasks

Under Locked Down, even your model provider's API is blocked until you explicitly allow it. That is the security model in miniature: an agent that goes rogue cannot phone home, exfiltrate your workspace to a paste site, or download a second stage unless you allowed that destination. Inspect rules with sbx policy ls and open one host with sbx policy allow network registry.npmjs.org.

Two related controls. Use secrets, not environment variables — the docs warn that environment variables are readable by processes inside the sandbox, while sbx secret set keeps the value on the host for the proxy to inject. And store registry pull credentials separately, for example gh auth token | sbx secret set --registry ghcr.io --password-stdin, or private image pulls fail as anonymous.

Picking a mode, including for many agents at once

The read-write default fits most days: edits appear in your working tree as a normal Git diff. --clone mounts the repo read-only and hands the agent a private clone — documented as the mode for running several agents against one repository, and for days you do not trust the diff. Mountless sandboxes share no host directory at all and move files with sbx cp. --rm deletes the session the moment the agent exits and returns its exit status, which is the CI shape of the tool. sbx run -d keeps a sandbox running after your session ends, and sbx move recreates its filesystem on Docker-managed cloud infrastructure.

Isolation alone does not solve parallelism. A separate dev.to write-up from a team running around 30 agents at a time on their own codebases reports what they changed: each session gets one area of the codebase plus a written description of what it owns, agents pick tasks from a shared board and mark them done with evidence, and a supervisor restarts crashed or rate-limited sessions so a failure costs a few minutes. The team packaged this as an open-source tool of their own, but the habits are tool-independent. Pair them with --clone and the two problems — blast radius and bookkeeping — stop compounding.

Is it worth it

Local sandbox compute is free, including for commercial use; cloud compute is a separate pay-as-you-go subscription and organization-wide policy governance is a separate paid plan. That pricing shape is also the honest sizing: this is a laptop-and-workstation product with a cloud escape hatch, not a fleet-management layer.

If you already run agents with approvals skipped, the trade is strongly in favour. Start on Balanced, switch any unattended job to Locked Down plus an explicit allowlist, and use --clone the moment more than one agent touches a repo.