Docker Sandboxes can give an agent sudo, let it install packages and give it a private Docker daemon. That is the point.
All of this happens inside a separate microVM. The agent gets its own kernel, internal filesystem, Docker daemon and network boundary.
Then Docker makes a much less dramatic choice: by default, your project directory is still mounted read-write.
So yes, the agent is sandboxed. And yes, it can still change your package.json, CI configuration or Git hooks. Both statements are true.
That makes Docker's model useful because it forces a better question than “is this sandboxed?”
The microVM protects the host, not automatically the work
Docker describes the microVM as the primary trust boundary.
Inside it, the agent has broad privileges. It can use sudo, install software, start containers and control its private Docker Engine. It does not share the host kernel or process memory.
The host Docker daemon is not directly available. Host localhost and private networking are outside the sandbox boundary. Outbound traffic can be mediated by network policy.
That is a meaningful improvement over running an agent directly in a user's shell. A questionable package installed by the agent stays in the VM instead of becoming another small archaeological layer on the main machine.
The workspace, however, is intentionally a bridge.
In direct mode, Docker mounts it read-write. Changes appear in the host working tree as the agent writes them.
The system can therefore protect /etc very well while still letting the agent edit the file you are about to execute thirty seconds later.
The risk is not limited to the visible diff
Docker's documentation calls out a particularly useful detail.
Inside the workspace, an agent may alter files that execute implicitly: package.json scripts, CI configuration, IDE tasks, Makefiles, agent project settings and other build files.
Git hooks deserve extra attention. They live under .git/ and may not appear in an ordinary git diff.
Docker therefore advises reviewing agent-authored workspace changes like an untrusted pull request before executing modified code.
That is more accurate than “it is in a VM, therefore everything is fine.”
System isolation can stop a process from reading your private files while still letting it add a surprisingly ambitious command to npm test. Security depends on which channels cross the boundary, not on what the box is called.
Clone mode moves the boundary
Docker offers another workspace mode with --clone.
Here, the host repository is mounted read-only and the agent works in a private clone inside the sandbox. Its edits no longer land directly in the local working tree.
For several agents running in parallel, or an agent you do not know well, that distinction matters more than the hypervisor branding.
Direct mode optimizes flow: changed files immediately appear on your machine.
Clone mode optimizes workspace isolation: you must deliberately bring the result back.
Neither is universally better. They encode different trust assumptions.
Credentials can stay outside the VM
The same design appears around secrets.
Docker can keep credentials on the host and have a proxy inject authentication into outbound HTTP requests. In that mode, raw credential values do not enter the microVM.
That reduces a familiar risk: giving an agent an API key and then discovering that some package it installed can read the same environment variable.
Networking is mediated as well. Docker documents controlled egress and blocking of non-HTTP protocols in the sandbox network model.
Again, that is not absolute safety. Allowing a domain still creates a channel to that domain. Docker even warns that broad wildcard rules can expose more services than their names suggest.
Even skills become shared trust
Recent Docker Sandboxes releases can import agent skills into a persistent store shared by multiple sandboxes.
That is convenient. Docker's own security documentation also calls it an exception to cross-sandbox isolation.
The store is mounted read-write. One participating sandbox can change instructions or scripts that another sandbox may load later. --no-share-skills opts out.
The little Markdown file teaching an agent how to work has become part of the security model. Humans have successfully reinvented shared dependencies, this time with more prose.
“Sandboxed” is not the useful question
Docker Sandboxes provides substantial isolation where coding agents need it: processes, kernel, Docker, networking and credentials can be separated from the host.
Its documentation also shows why the more useful question is: what is the agent still allowed to modify or send across the boundary?
With a shared workspace, that channel is your project files. With allowed networking, it is an outbound path. With shared skills, it is persistent executable instruction shared across agents.
A sandbox does not make an agent trustworthy.
It lets you decide more precisely where you are willing not to trust it.