Claude Code, with the right prompting, can deliver some undeniably impressive results. However, it’s also capable of making some pretty bad (and dangerous) decisions, especially when running unsandboxed on your system. It can delete files, overwrite configs, mess with things outside your project scope, etc. Thus, sandboxes are a necessity for running CC in YOLO (--dangerously-skip-permissions) mode.
Conveniently, Docker offers Docker Sandboxes, which you can use to isolate CC (or coding agent of choice) from your system.
Claude Code permission prompting
Claude Code runs in your local environment, and has access to theoretically everything that you have access to, including your filesystem, your credentials, and your active processes. This is generally fine when you’re supervising it and manually approving each action. When you’re skipping permission prompts (or not thoroughly reviewing every action it proposes), there’s too much at stake to run it outside a sandbox.
Many devs want to run CC in YOLO mode overnight or when they’re AFK, hence the trend of buying Mac Minis solely for this purpose, instead of putting their main system in harm’s way. Claude Code also recently rolled out auto mode, which applies an LLM-based filter to approve/deny CC actions based on how a classifier interprets them.
What are Docker Sandboxes?
Docker Sandboxes are isolated environments designed for running coding agents, especially fully-autonomously. Each sandbox runs in its own lightweight microVM, which is a harder boundary than a container between the agent and your machine.
This sets guardrails at the infrastructure level, instead of on Claude Code itself. This means you have more free reign within your sandbox, as the blast radius for any dangerous/malicious commands is contained, and worst case you can just launch a fresh sandbox with the sbx command. When set up properly (important!), sandboxes are the recommended way to run CC in --dangerously-skip-permissions mode without risking harm to your machine. In fact, CC by default is launched in YOLO mode when you run it in sbx.
Right now, there are a lot of agent sandboxes on the market. What sets Docker Sandboxes apart is that they’re designed to run locally, and they use microVM isolation. This makes them well suited for local dev workflows and long-running tasks.
How to use Docker Sandboxes with Claude Code
Install the sbx CLI:
on macOS
brew install docker/tap/sbx
on Windows
winget install Docker.sbx
Log in with your Docker account:
sbx login
From there, you’ll need to choose a network policy:
- open (all traffic allowed)
- balanced (common dev sites allowed, everything else blocked)
- locked down (all traffic blocked unless explicitly permitted)
You can then run Claude Code via:
sbx run claude -- "write unit tests for the user page"
More info on Claude Code in Docker Sandboxes
The sandbox provisions from this command, and tears down when the task is complete. You can also shell into a running sandbox if you want to observe mid-task.
What about Claude Code’s /sandbox?
CC has a slash command that sandboxes your session. However, this is a lighter sandbox than Docker’s, and runs on your host machine instead of its own microVM. It also notifies you when CC tries to do something outside the sandbox, so you can respond appropriately.
Read more about CC’s sandbox mode.
Environments for Claude Code
When you’re developing with Claude Code, you’ll want to make sure that every new feature is tested extensively in a secure, isolated environment. Ephemeral environments pair beautifully with CC: you can spin up an environment automatically based on a branch/PR, run tests, do QA, push patches, and then merge once you’ve determined it’s ready.
Shipyard is a plug-and-play ephemeral environment solution for devs using Claude Code. Claude can interact with the environments on its own via MCP/CLI (pull logs, get each live URL, visit the environments with Playwright MCP, etc). Try it free for 30 days and see how much faster your dev/test loop gets.
