# Sandbox Isolation for Coding Agents
> **Confidence**: Tier 2 — Official Docker docs + verified vendor documentation
> **Reading time**: ~10 minutes
> **Scope**: Running Claude Code safely in isolated environments
---
## TL;DR
| Solution | Isolation | Local/Cloud | Best For |
|----------|-----------|-------------|----------|
| **Docker Sandboxes** | microVM | Local | Daily autonomous dev work |
| **Fly.io Sprites** | Firecracker microVM | Cloud | API-driven agent workflows |
| **E2B** | Firecracker microVM | Cloud | Multi-framework AI apps |
| **Vercel Sandboxes** | Firecracker microVM | Cloud | Next.js / Vercel ecosystem |
| **Cloudflare Sandbox SDK** | Container | Cloud | Workers-based serverless |
| **Native CC sandbox** | Process-level | Local | Lightweight, no Docker needed |
Quick start:
```bash
docker sandbox run claude ~/my-project
```
---
## 1. The Problem: Safe Autonomy
Claude Code's permission system protects you from unintended actions. But it creates a tension:
- **`--dangerously-skip-permissions`** removes all guardrails — Claude can `rm -rf`, `git push --force`, or `DROP TABLE` without asking. On a bare host, this is dangerous.
- **Permission fatigue** — approving every file edit and shell command slows down autonomous workflows. For large refactors or CI pipelines, interactive approval is impractical.
- **The gap**: How do you run Claude Code autonomously AND safely?
**Answer**: Isolate the execution environment. Let the agent run free inside a sandbox where the blast radius is contained. The sandbox is the security boundary, not the permission system.
---
## 2. Isolation Approaches
```mermaid
flowchart TD
A[Need autonomous Claude Code] --> B{Where?}
B -->|Local development| C{Docker Desktop available?}
B -->|CI/CD pipeline| D[Cloud sandbox]
B -->|Serverless / API| E[Cloudflare Sandbox SDK]
B -->|Minimal setup| F[Native CC sandbox mode]
C -->|Yes| G[Docker Sandboxes
microVM isolation]
C -->|No| F
D --> H{Preference?}
H -->|Persistent VMs| I[Fly.io Sprites]
H -->|Open-source| J[E2B]
H -->|Vercel ecosystem| K[Vercel Sandboxes]
```
---
## 3. Docker Sandboxes
> **Source**: [docs.docker.com/ai/sandboxes/](https://docs.docker.com/ai/sandboxes/)
> **Requires**: Docker Desktop 4.58+ (macOS or Windows)
Docker Sandboxes run AI coding agents in microVM-based isolation on your local machine. Each sandbox gets its own private Docker daemon and filesystem. Sandboxes do NOT appear in `docker ps` — they are VMs, not containers.
### Quick Start
```bash
# Create and run a sandbox with your project
docker sandbox run claude ~/my-project
# Run with autonomous mode (safe inside sandbox)
docker sandbox run claude ~/my-project -- --dangerously-skip-permissions
# Pass a prompt directly
docker sandbox run claude ~/my-project -- "Refactor auth module to use JWT"
# Continue a previous session
docker sandbox run my-sandbox -- --continue
```
### Architecture
```
┌──────────────────────────────────────────────────────────┐
│ HOST MACHINE │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ DOCKER SANDBOX (microVM) │ │
│ │ │ │
│ │ ┌──────────────┐ ┌───────────────────────────┐ │ │
│ │ │ Claude Code │ │ Private Docker daemon │ │ │
│ │ │ (--dsp mode) │ │ (isolated from host) │ │ │
│ │ └──────────────┘ └───────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Workspace: ~/my-project (synced with host) │ │ │
│ │ │ Same absolute path as host │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ Base: Ubuntu, Node.js, Python 3, Go, Git, │ │
│ │ Docker CLI, GitHub CLI, ripgrep, jq │ │
│ │ User: non-root 'agent' with sudo │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ Host Docker daemon: NOT accessible from sandbox │
│ Host filesystem: NOT accessible (except workspace) │
└──────────────────────────────────────────────────────────┘
```
Key properties:
- **Workspace sync**: Host directory mounts at the same absolute path inside the sandbox
- **Full isolation**: Agent cannot access host Docker daemon, host containers, or files outside workspace
- **Private Docker**: Each sandbox has its own Docker daemon for building/running containers
- **Claude runs with `--dangerously-skip-permissions`**: Intentional — the sandbox is the security boundary
### Network Policies
Control what the sandbox can access on the network.
```bash
# View network activity
docker sandbox network log my-sandbox
# Set up denylist mode (block all, allow specific)
docker sandbox network proxy my-sandbox \
--policy deny \
--allow-host api.anthropic.com \
--allow-host "*.npmjs.org" \
--allow-host "*.pypi.org" \
--allow-host github.com
# Set up allowlist mode (allow all, block specific)
docker sandbox network proxy my-sandbox \
--policy allow \
--block-host "*.malicious-domain.com" \
--block-cidr "192.168.0.0/16"
```
| Mode | Default behavior | Use case |
|------|-----------------|----------|
| **Allowlist** (default) | Permits most traffic, blocks specific destinations | General development |
| **Denylist** | Blocks all traffic, allows only specified destinations | High-security environments |
**Default blocked ranges**: Private CIDRs (`10.0.0.0/8`, `127.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `169.254.0.0/16`) and IPv6 equivalents.
**Pattern matching**: Exact (`example.com`), port-specific (`example.com:443`), wildcards (`*.example.com` matches subdomains only). Most specific pattern wins.
**Security caveat**: Domain filtering does not inspect traffic content. Broad allowances (e.g., `github.com`) permit access to user-generated content. HTTPS inspection is not performed in bypass mode.
**Config storage**: Per-sandbox at `~/.docker/sandboxes/vm/[name]/proxy-config.json`. Policies persist across restarts.
### Custom Templates
For teams needing reproducible environments with specific tooling:
```dockerfile
FROM docker/sandbox-templates:claude-code
USER root
# Install project-specific dependencies
RUN apt-get update && apt-get install -y \
postgresql-client \
redis-tools
# Install global npm packages
RUN npm install -g pnpm turbo
USER agent
```
Build and use:
```bash
# Build the template
docker build -t my-team-sandbox:v1 .
# Create sandbox with custom template
docker sandbox create my-sandbox \
--template my-team-sandbox:v1 \
--load-local-template ~/my-project
```
Use custom templates when: team environments, specific tool versions, repeated setups, complex configurations. For simple one-off work, use the defaults and let the agent install what it needs.
### Commands Reference
| Command | Description |
|---------|-------------|
| `docker sandbox run ` | Create and start a sandbox |
| `docker sandbox create ` | Create without starting |
| `docker sandbox ls` | List all sandboxes |
| `docker sandbox run -- "prompt"` | Pass a prompt |
| `docker sandbox run -- --continue` | Continue previous session |
| `docker sandbox run -- --dsp` | Short for --dangerously-skip-permissions |
| `docker sandbox network proxy ` | Configure network policies |
| `docker sandbox network log ` | View network activity |
### Authentication
**Option 1: API key (recommended for headless)**
Set `ANTHROPIC_API_KEY` in `~/.bashrc` or `~/.zshrc`. The sandbox daemon reads from these files, not the current shell session. Restart the daemon after changes. Persists across sandbox recreation.
**Option 2: Interactive login (per-session)**
Triggered automatically if no credentials found. Use `/login` inside Claude Code to trigger manually. Authentication does NOT persist when the sandbox is destroyed.
### Supported Agents
| Agent | Provider | Status |
|-------|----------|--------|
| Claude Code | Anthropic | Full support |
| Codex CLI | OpenAI | Supported |
| Gemini CLI | Google | Supported |
| cagent | Docker | Supported |
| Kiro | AWS | Supported |
### Limitations
- **macOS and Windows only** for microVM mode. Linux uses legacy container-based sandboxes (Docker Desktop 4.57+).
- **Docker Desktop required** — not available with standalone Docker Engine.
- **MCP Gateway not yet supported** inside sandboxes.
- **No GPU passthrough** — not suitable for ML training workloads.
- **Workspace sync is one-way**: changes inside the sandbox propagate to the host, but concurrent host edits may conflict.
---
## 4. Alternatives Landscape
### Fly.io Sprites
> **Source**: [sprites.dev](https://sprites.dev)
Hardware-isolated execution environments built on Firecracker microVMs, by Fly.io.
- **Isolation**: Firecracker microVMs with full hardware isolation
- **Persistence**: Fully mutable ext4 filesystem, automatic 100GB partition
- **Checkpoint/restore**: Live checkpoints in ~300ms (copy-on-write), restore under 1 second
- **HTTP access**: Individual URLs per Sprite, auto-activation on requests (cold-start under 1s)
- **Network**: Layer 3 egress policies, public/private toggles
- **Resources**: Up to 8 CPUs, 16GB RAM per Sprite
- **API**: CLI (`sprite` command), REST API, JavaScript and Go client libraries
- **Pricing**: Pay-per-use ($0.07/CPU-hour, $0.04/GB-hour). $30 trial credits.
### Cloudflare Sandbox SDK
> **Source**: [developers.cloudflare.com/sandbox/](https://developers.cloudflare.com/sandbox/)
Secure code execution in isolated containers, built on Cloudflare's Workers platform.
- **Isolation**: Containers (not microVMs) on Cloudflare's serverless runtime
- **Languages**: Python, JavaScript/TypeScript, shell commands
- **Persistence**: R2 bucket mounting as local filesystem paths
- **API**: TypeScript SDK (`getSandbox()`, `exec()`, `runCode()`, file ops, WebSocket)
- **Integration**: Claude generates code, Sandbox executes it, results return as text/visualizations
- **Pricing**: Workers Paid plan required. Based on Containers platform pricing.
- **Tutorial**: [developers.cloudflare.com/sandbox/tutorials/claude-code/](https://developers.cloudflare.com/sandbox/tutorials/claude-code/)
### Vercel Sandboxes
> **Source**: [vercel.com/docs/vercel-sandbox/](https://vercel.com/docs/vercel-sandbox/)
Ephemeral Linux microVMs for AI agents and code generation, GA since 2026-01-30.
- **Isolation**: Firecracker microVMs, isolated from env vars, DBs, and cloud resources
- **Performance**: Sub-second initialization, automatic termination on task completion
- **Timeouts**: Default 5 min, Hobby up to 45 min, Pro/Enterprise up to 5 hours
- **SDK**: `Sandbox`, `Command`, `Snapshot` classes. Filesystem snapshots for faster repeated runs.
- **Auth**: Vercel OIDC tokens (recommended) or access tokens for external CI/CD
- **Integration**: Works with Claude's Agent SDK for autonomous agent tasks
### E2B
> **Source**: [e2b.dev](https://e2b.dev)
Open-source sandbox platform for AI agents and LLM applications.
- **Isolation**: Firecracker microVMs (same technology as AWS Lambda)
- **Performance**: ~150ms cold boot, under 25ms standby resume
- **Custom images**: Up to 10GB, boot in under 2 seconds (Blueprints)
- **Snapshots**: Capture and restore full VM state
- **Languages**: Python, JavaScript, Ruby, C++, anything on Linux. LLM-agnostic.
- **Integrations**: LangChain, LangGraph, LlamaIndex, Vercel/Next.js, Ollama
- **Deployment**: Cloud-hosted, BYOC (AWS/GCP/Azure), self-hosted on-premises/VPC
- **Pricing**: Free tier ($100 credits, 1h max), Pro from $150/month (24h max)
### Native Claude Code Sandbox Mode
> **Source**: [code.claude.com/docs/en/sandboxing](https://code.claude.com/docs/en/sandboxing)
Claude Code's built-in process-level sandboxing (Layer 4 in the [architecture](./architecture.md)).
- **No external dependencies**: Works out of the box
- **Process isolation**: Restricts what commands Claude can execute
- **Configurable**: Through `allowedTools` in settings
- **Limitations**: Not full VM isolation — shares host kernel and filesystem
Use this when: Docker is unavailable, lightweight isolation is sufficient, or you want defense-in-depth alongside a sandbox.
---
## 5. Comparison Matrix
| Criterion | Docker Sandboxes | Fly.io Sprites | Cloudflare SDK | E2B | Vercel Sandboxes | Native CC |
|-----------|-----------------|----------------|----------------|-----|-----------------|-----------|
| **Isolation level** | microVM | Firecracker microVM | Container | Firecracker microVM | Firecracker microVM | Process |
| **Runs locally** | Yes | No (cloud) | No (cloud) | No (cloud) | No (cloud) | Yes |
| **Docker-in-Docker** | Yes (private daemon) | Yes | No | Yes | Yes | N/A |
| **Network control** | Allow/Deny lists | L3 egress policies | Not detailed | Not detailed | Not detailed | N/A |
| **Platform** | macOS, Windows | Any (API) | Any (Workers) | Any (API/SDK) | Any (SDK) | Any |
| **Free tier** | Docker Desktop | $30 credits | Workers Paid | $100 credits | Yes (limited) | Free |
| **Best for** | Local dev | API-driven agents | Serverless | Multi-framework | Next.js/Vercel | Minimal setup |
---
## 6. Safe Autonomy Workflows
### Pattern: Docker Sandbox + --dangerously-skip-permissions
The recommended pattern for local autonomous development:
```bash
# 1. Create a sandbox with your project
docker sandbox create my-feature ~/my-project
# 2. Configure network (optional, recommended for security)
docker sandbox network proxy my-feature \
--policy deny \
--allow-host api.anthropic.com \
--allow-host "*.npmjs.org" \
--allow-host github.com
# 3. Run Claude autonomously (safe inside sandbox)
docker sandbox run my-feature -- --dangerously-skip-permissions \
"Refactor the auth module to use JWT. Run all tests before finishing."
# 4. Review changes on host (workspace syncs automatically)
cd ~/my-project && git diff
# 5. If satisfied, commit. If not, discard or re-run.
git add -A && git commit -m "feat: JWT auth (sandbox-generated)"
```
### Pattern: CI/CD Pipeline with Sandbox
Sketch for GitHub Actions:
```yaml
jobs:
agent-task:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Claude in E2B sandbox
uses: e2b-dev/e2b-github-action@v1
with:
api-key: ${{ secrets.E2B_API_KEY }}
command: |
claude --dangerously-skip-permissions \
-p "Run the full test suite and fix any failures"
```
For CI/CD, cloud sandboxes (E2B, Vercel, Sprites) are typically better than Docker Sandboxes since they don't require Docker Desktop.
---
## 7. Anti-Patterns
| Anti-pattern | Why it's dangerous | Do instead |
|-------------|-------------------|------------|
| `--dangerously-skip-permissions` without sandbox | Agent has unrestricted access to host filesystem, network, and Docker | Use a sandbox as the security boundary |
| Assuming containers = VMs | Containers share the host kernel. A container escape exposes the host. | Use microVM-based solutions (Docker Sandboxes, E2B, Sprites) for strong isolation |
| Mounting entire filesystem into sandbox | Defeats the purpose of isolation. Agent can access credentials, SSH keys, etc. | Mount only the project workspace directory |
| Allowlisting `*` in network policies | Agent can exfiltrate data to any endpoint | Use denylist mode with explicit allowances |
| Skipping `git diff` review after sandbox run | Autonomous agent may have made unintended changes | Always review diffs before committing sandbox-generated code |
| Using sandbox as excuse to skip code review | Isolation protects the host, not code quality | Sandbox + code review are complementary, not alternatives |
---
## See Also
- [architecture.md](./architecture.md) — Layer 4 (Sub-Agent Architecture) and permission model
- [security-hardening.md](./security-hardening.md) — MCP vetting, injection defense, CVE tracking
- [code.claude.com/docs/en/sandboxing](https://code.claude.com/docs/en/sandboxing) — Official Claude Code sandbox docs
- [docs.docker.com/ai/sandboxes/](https://docs.docker.com/ai/sandboxes/) — Docker Sandboxes documentation