Docker Sandboxes is a free CLI tool, sbx, that runs an AI coding agent — Claude Code, Copilot CLI, Codex, Gemini CLI, Kiro, or your own — inside a disposable microVM instead of directly on your machine. The agent gets its own filesystem, its own Docker daemon, and its own network, so you can hand it --dangerously-skip-permissions and walk away without it touching your host.
Short answer: Install the free
sbxCLI (brew install docker/tap/sbxon macOS), runsbx run claudefrom your project folder, and the agent works inside a microVM with its own kernel and filesystem. Delete the sandbox and spin up a clean one in seconds. Core sandboxes are free; centralized policy controls need a paid Docker Team ($15/user/month) or Business ($24/user/month) plan.
I set this up on a MacBook to test a specific worry: what happens when you give an agent full autonomy — no approval prompts, no "are you sure" — on a real project. I ran Claude Code inside a sandbox in YOLO mode on a scratch repo, let it install packages and run a build without asking me anything, then deliberately told it to rm -rf a directory outside the mounted workspace to see what happened. Here's what the setup actually involves and where I'd still be careful.
What you'll need
A Mac, Windows, or Linux machine — Docker Desktop is not required, sbx is a standalone binary. On macOS you'll need Homebrew; on Linux, KVM support and a user added to the kvm group (the installer handles this with sudo usermod -aG kvm $USER). You don't need a Docker Hub subscription for the core tool: sbx is free to install and use, including for commercial work, per Docker’s docs. You'll only need a paid Docker Team or Business plan if you want an org admin to enforce network, filesystem, or MCP policy across everyone's machine instead of leaving each developer to configure it locally. Have a project folder ready and whichever coding agent you use already installed — Claude Code, Codex, or GitHub Copilot’s CLI all work.
Step-by-step: setting up Docker Sandboxes
1. Install the sbx CLI
On macOS: brew trust docker/tap && brew install docker/tap/sbx. On Windows: winget install -h Docker.sbx. On Linux: curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh, then sudo apt-get install docker-sbx, followed by the kvm group step above. In my testing on macOS, the Homebrew install took under two minutes, most of it just Homebrew resolving dependencies.
2. Log in
Run sbx login. This opens a browser flow tied to your Docker ID. One commenter on the tool's Hacker News launch thread flagged that the login expires every few days, which is annoying if you're scripting sandbox creation into CI — worth knowing before you build automation around it.
3. Launch a sandbox from your project folder
cd into your repo and run sbx run claude (swap claude for copilot, codex, gemini, or kiro). Only that project directory gets mounted into the microVM — the agent can't see the rest of your filesystem. In my testing, the sandbox was ready and the agent was prompting me in under 10 seconds on an M-series Mac.
4. Turn on unattended mode deliberately
If you want the agent to work without approval prompts, pass its own YOLO-style flag — for Claude Code that's --dangerously-skip-permissions. Outside a sandbox I wouldn't run that flag on a real project. Inside one, that's the entire point: the blast radius is the microVM, not your laptop.
5. Set a network allow or deny list
By default the sandbox has outbound network access, which matters if you're worried about an agent exfiltrating a secret or fetching something it shouldn't. sbx supports allow and deny lists so you can, for example, block everything except your package registry and git remote. I tested this by denying a domain and confirming the agent's curl to it failed inside the sandbox while the rest of its network access kept working.
6. Let it run, then discard the sandbox
When the agent finishes — or goes somewhere you didn't intend — delete the sandbox and start a fresh one rather than trying to clean up its state by hand. That reset is the actual value: I ran the rm -rf test above, confirmed the sandbox's own filesystem got wrecked, then killed it and had a clean one running again in a few seconds with my host completely untouched.
Example prompts you can copy
Once the agent is running inside a sandbox, these worked well in my testing to lean into the fact that it can act without asking:
- "Set up the full dev environment for this repo — install dependencies, run the test suite, and fix any failing tests. Don't ask me before installing packages."
- "Build a Docker container for this app, run it, and hit the health endpoint to confirm it starts cleanly. You have your own Docker daemon in here, use it."
- "Refactor the auth module to use the new API client, run the existing tests after each change, and keep going until they pass without stopping to check in with me."
- "Try three different approaches to fix this failing CI job in parallel branches, then tell me which one actually passes and why."
That last one is the kind of prompt I wouldn't give an agent outside a sandbox — trying multiple destructive approaches in parallel is exactly the scenario a disposable, isolated environment is built for.
Common mistakes to avoid
The first mistake is running YOLO mode outside a sandbox because it's faster to skip the install step — that defeats the entire point, and it's the scenario Docker Sandboxes exists to prevent. Second, assuming microVM isolation means no network isolation is needed; by default the sandbox can still reach the internet, so if you're worried about a leaked API key or a prompt-injection attack pulling in a malicious script, set the deny list yourself instead of assuming it's on. Third, treating the login session as permanent — it expires every few days per user reports on the launch thread, which will silently break a scheduled or CI-triggered sandbox run if you don't handle re-auth. Fourth, forgetting that only the project folder you mounted is isolated; anything you explicitly bind-mount in from outside that folder is exposed to the agent just like it would be on your host. Fifth, expecting Linux support to match macOS and Windows maturity — Linux wasn't part of the initial January 2026 launch and only shipped later, so check the current docs for your distro before assuming feature parity. And sixth, using a sandbox as your only safeguard on a project with real credentials in the environment — a hard security boundary around the filesystem and kernel is not the same as auditing what secrets you handed the agent access to.
Docker Sandboxes vs. plain YOLO mode vs. a cloud sandbox (e2b)
Docker Sandboxes (sbx) |
Running the agent's own YOLO flag, no sandbox | Cloud sandbox service (e.g. e2b) | |
|---|---|---|---|
| Isolation | Hypervisor-based microVM, own kernel | None — full access to your machine | Isolated cloud VM/container, off your machine |
| Cost | Free core CLI; governance needs Team ($15/user/mo) or Business ($24/user/mo) | Free (it's just a flag) | Usage-based, typically metered by session/compute time |
| Setup | One CLI install, minutes | None | Account + API integration required |
| Runs where | Your own hardware | Your own hardware | Vendor's cloud |
| Best for | Local, unattended agent runs you want fully contained | Never, on anything you care about | CI pipelines or hosted agent products that shouldn't touch a dev's laptop at all |
In my testing, sbx is the right call when you want unattended agent work on your own machine without the blast radius of a bare YOLO flag. If you're running agents as part of a hosted product or CI pipeline where you don't want them anywhere near a developer's laptop in the first place, a cloud sandbox service is the better fit — different problem, not really a competitor.
Tools that make this easier
If you haven't set up the agent itself yet, start with my guide to Claude Code or the general Claude AI walkthrough before layering a sandbox on top. If you're running Codex instead, my ChatGPT Codex guide covers the CLI setup Docker Sandboxes wraps around. Running more than one agent at once on the same repo brings a different problem — merge collisions, not host safety — which my guide to a local merge queue for parallel Claude Code agents covers. And if you're still deciding which coding agent is worth the setup time at all, my honest review of AI programming tools and my tested picks for the best AI tool for code are the two guides I'd read first.
My verdict
Docker Sandboxes solved the specific problem I tested it against: I could not get an unattended, full-permission agent to touch anything outside its own microVM, even when I told it to try. The setup is genuinely fast — a couple of minutes on macOS, one command to launch — and free for solo use. Where I'd still be cautious is the network default (open unless you lock it down yourself) and the login expiry, which turns "set it and forget it" into "set it and check back every few days." If you're already running agents in unattended mode, this is a real safety upgrade over nothing; it isn't a substitute for thinking about what secrets and network access you hand the agent in the first place.
Frequently Asked Questions
Are Docker Sandboxes for AI agents free?
Yes, the core sbx CLI is free to install and use, including for commercial work, per Docker’s documentation. You only pay if you want Docker AI Governance's centralized policy controls, which come with a Docker Team plan ($15/user/month billed annually) or Business plan ($24/user/month), per Docker’s pricing page.
How long does it take to set up Docker Sandboxes?
In my testing on macOS, the Homebrew install took under two minutes, and launching a sandbox with sbx run claude had the agent ready in under 10 seconds. Linux setup takes a bit longer since you're adding your user to the kvm group and may need to restart your session for it to take effect.
What's the easiest way to try it?
Install sbx, run sbx login once, then cd into any low-stakes project and run sbx run claude. Test it the way I did — give the agent an unattended task and try to get it to affect something outside the sandbox — before trusting it with a real project.
Does this replace normal permission prompts entirely?
No, and it shouldn't. The sandbox is what makes it safe to skip those prompts, but you still choose whether to pass a YOLO-style flag like --dangerously-skip-permissions. Outside a sandbox I wouldn't use that flag on anything that matters.
Is Linux support as mature as macOS and Windows?
Not quite yet. Docker's own January 2026 announcement didn't include Linux at launch, and while the current docs now include a full Ubuntu install path with KVM and a kvm group step, I'd expect rougher edges there than on macOS or Windows until it's had more time in the field.