Almost everyone who lets the agent control the code for more than five minutes eventually disables confirmations. Claude Code — --dangerously-skip-permissions, Codex — --full-auto, and so on. And that makes sense: an agent that asks for permission for every ls wastes time instead of saving it. The question is only: what stands between this agent and your machine.
Usually, nothing.
What exactly do you allow
An autonomous-mode agent is a process with your permissions that decides by itself what to execute in the shell. It can see ~/.ssh, ~/.aws, ~/.config/gh, browser cookies, neighboring work repositories, and shell history. Not because it is evil, but because you launched it that way: your uid, your $HOME.
Then it takes one of three possibilities: the agent misinterpreted the task and executed rm -rf in the wrong directory; the context included an instruction from an external source (GitHub issue, README dependencies, contents of a web page) and the agent executed it; the agent installed a package whose postinstall contained the wrong code. The third scenario has already been discussed on the forum — the worm Shai-Hulud in npm was collecting tokens in exactly this way.
Isolation of the agent solves exactly one problem: to limit the radius of damage when the agent does something wrong. It does not make the agent smarter and does not protect the project you gave it access to from being damaged.
First boundary: the container. What it holds
The most common answer is “run it in Docker.” It works, but it helps to understand where the boundary actually lies.
A container is a process on your kernel, isolated by namespaces (PID, mount, net, user) and limited by cgroups, seccomp and capabilities. The filesystem is isolated, the network is isolated, other processes are not visible. For an “agent accidentally deleted a directory,” this is enough: it will delete it inside the container.
What the container does not hold:
- The host kernel. Any vulnerability in the kernel syscall interface is a potential escape to the host. Such CVEs come out regularly.
- What you passed through yourself.
-v /var/run/docker.sock:/var/run/docker.sock— that’s root on the host with a single command.--privileged— the same. And the agent often needs Docker: it wants to build an image, start a database, run integration tests. - Mounted project directory. It is mounted as writable, otherwise there’s no point.
Devcontainers in VS Code are convenient, but by threat model they are the same container. If inside the dev container the agent gains access to the host Docker socket (a popular way for “docker inside to work”), isolation is reduced to zero.
Second boundary: microVM. What Docker did
In April 2026 Docker released the Docker Sandboxes and the sbx utility — a wrapper that runs the agent in a microVM rather than in a container. In August the product resurfaced on Hacker News, so I’ll clarify right away: this is not a fresh release; the tool has been around since spring.
The key difference from a container is its own kernel. Each sandbox gets its own VM with its own kernel, its own networking stack, and its own Docker daemon inside. Escape requires not a kernel syscall bug, but a bug in the hypervisor — a boundary of a fundamentally different class.
The interesting part is how it is implemented cross-platform. In Docker’s engineering blog they explain why they did not adopt Firecracker: it “is designed for cloud infrastructure, specifically Linux/KVM environments like AWS Lambda” and “does not have native support for macOS or Windows.” So they wrote their own VMM that uses the native hypervisor of each OS:
| OS | Hypervisor |
|---|---|
| macOS | Apple Hypervisor.framework |
| Windows | Windows Hypervisor Platform |
| Linux | KVM |
Docker Desktop is not required — sbx is installed separately.
Official illustration of Docker Sandboxes. Source: docker.com
Installation: brew install docker/tap/sbx (macOS), winget install Docker.sbx (Windows), on Linux — via apt from the Docker repository. Then sbx login and sbx run claude in the project directory.
What sbx can actually do
A list of subcommands from the official CLI reference — the best indicator of what the tool is designed for:
| Command | Purpose |
|---|---|
sbx run <agent> |
raise a sandbox and run the agent in it |
sbx ls / sbx stop / sbx rm |
list, stop, remove sandboxes |
sbx exec |
execute a command inside an already started sandbox |
sbx cp |
copy files between host and sandbox |
sbx policy |
allow / deny / check — network restrictions |
sbx secret |
set, ls, rm, import — manage secrets separately from code |
sbx mcp |
add, ls, rm, inspect, auth — connect to MCP servers |
sbx ports |
expose a port from the sandbox to the outside |
sbx template |
environment templates |
sbx tui |
interactive panel |
Out of the box supported are claude, codex, copilot, cursor, gemini, kiro, opencode, droid, docker-agent and simply shell. The sbx itself is free, including commercial use; money is charged for the Docker AI Governance — centralized application of network, file, and MCP policies across all machines in an organization plus audit-logs. For a lone individual this is not needed, for a team of thirty it’s exactly what you pay for.
Docker says that a “cold start is fast,” but there are no concrete numbers — milliseconds of startup, memory overhead — in the blog. This is a vendor claim, not a measurement. If it’s important for you to boot dozens of sandboxes in parallel, measure it yourself; I did not find any verified benchmarks.
Four levels, and what each one costs
| Option | Boundary | What survives the escape | Price |
|---|---|---|---|
| Agent on host | no | nothing | 0, but $HOME is fully open |
| Container / devcontainer | namespaces, shared kernel | everything except mounted volumes and sockets | almost 0, but docker-in-docker breaks the model |
microVM (sbx, Firecracker, Lima) |
its own kernel + hypervisor | host fully, except for the forwarded directory | seconds to start, memory for VM |
| Separate machine / VPS | physical | everything | money, latency, complexity of sync |
Practical rule: if the agent works with a single repository and does not touch production — a container is sufficient. If you enable full autonomy, give access to Docker and go drink coffee — go with a microVM. If the agent has access to production keys — don’t choose any of these options; remove the keys.
Five things the sandbox does not fix
Secrets you yourself handed over. The agent needs a GitHub token to create a PR. Inside the sandbox it can see it. sbx secret manages storage, but not what the agent will do with the secret.
Push to a repository. File system isolation does not prevent the agent from pushing broken code. A separate branch and mandatory reviews protect better than a hypervisor — there is a discussion about disciplined reviews on the forum stacked PR.
MCP servers. Each connected MCP is an external-facing channel, often with its own authorization. The sandbox limits the process, not the token’s rights inside the MCP.
Supply chain. The agent inside an isolated VM still performs npm install, and the malicious code will still run — just inside the VM. If credentials were there, they leaked.
The project itself. The directory is mounted writable — otherwise the agent is useless. The only protection here is git and backups, not isolation.
A separate note on privacy: Docker Sandboxes require sbx login, i.e., a Docker account. What exactly is sent to telemetry when using policies and governance — check your jurisdiction and company policy before you run internal code through this. For sensitive projects an autonomous option is a local VM (Lima, Multipass, pure QEMU/KVM), without an external account.
If you don’t want to depend on Docker
On Linux, all of this is built by hand and for free: qemu-system-x86_64 with -enable-kvm and forwarded directory via virtiofs, or Lima, or ordinary multipass. On macOS, the same role is played by Lima on top of vz. More expensive to set up at the start, but without an account and without a vendor in the chain. If you want it to be really simple and you agree to container-level borders — take the usual docker run with --network none where the agent doesn’t need a network at all.
Do you give the agent full autonomy? And if yes — what stands between it and your ~/.ssh: a container, a VM, a separate machine, or nothing? Interested in real configs, not intentions.
Sources
- Docker Sandboxes — product page
- Why MicroVMs: The Architecture Behind Docker Sandboxes — Docker engineering blog, April 16, 2026
- Docker Sandboxes Documentation
- CLI reference
sbx