Claude Code Sandboxing: Run Agents Safely Without Permission Fatigue

claude-codesecuritysandboxingdocker

If you’ve used Claude Code, you know the drill: approve this bash command, approve that file write, approve network access… repeat ad infinitum. It’s secure, but it kills flow. Anthropic’s answer? Native sandboxing that reduces permission prompts by 84% while actually increasing security.

The Problem: Approval Fatigue

Without sandboxing, Claude Code asks permission for nearly every operation. Makes sense from a safety perspective—you don’t want an AI agent running arbitrary commands on your system. But in practice, you end up clicking “yes” mindlessly, which defeats the purpose.

The Solution: OS-Level Sandboxing

Claude Code’s sandboxing creates defined security boundaries upfront, so the agent can work freely within those boundaries without constant interruption.

How It Works

Two isolation layers:

1. Filesystem isolation — Read/write access to your current working directory, blocked from sensitive system locations
2. Network isolation — All traffic routes through a proxy outside the sandbox; no direct network access from within

Platform Implementation

• Linux: Uses bubblewrap with bind mounts and network namespace removal
• macOS: Uses sandbox-exec with dynamically generated Seatbelt profiles

All child processes inherit the same restrictions—no escape hatches.

How to Enable

Quick start:

/sandbox

That’s it. The slash command activates sandboxed bash with sensible defaults.

Persistent Configuration

Add to ~/.claude/settings.json or .claude/settings.json:

{
  "sandbox": {
    "enabled": true
  }
}

Fine-Grained Control

The standalone sandbox runtime (@anthropic-ai/sandbox-runtime) supports detailed configuration in ~/.srt-settings.json:

{
  "filesystem": {
    "denyRead": ["/etc/passwd", "/etc/shadow"],
    "allowWrite": ["./"],
    "denyWrite": ["/usr", "/bin", "/sbin"]
  },
  "network": {
    "allowedDomains": ["github.com", "npmjs.com"],
    "deniedDomains": ["*"]
  }
}

Docker Sandboxes: Container-Level Isolation

Docker takes a different approach. While Claude Code’s native sandbox restricts the agent process itself, Docker argues this leads to constant host system access requests. Docker Sandboxes (Docker Desktop 4.50+) provide system-level isolation—the agent runs in a full containerized environment.

Quick Start

docker sandbox run claude

That’s it. Docker creates an isolated container with your current directory mounted.

How It Works

When you run docker sandbox run <agent>:

1. Creates a container from a template image
2. Mounts your workspace at the same absolute path (e.g., /Users/alice/projects/myapp on host = same path in container)
3. Auto-discovers Git user.name/user.email and injects into container
4. Prompts for authentication on first run
5. Starts the agent with bypass permissions enabled

Sandbox Persistence

Docker enforces one sandbox per workspace. Running docker sandbox run claude in the same directory reuses the existing container. State persists—installed packages, temp files, everything stays between sessions.

Advanced Usage

# Environment variables
docker sandbox run claude -e API_KEY=xxx -e DEBUG=true

# Mount Docker socket for Docker-in-Docker
docker sandbox run claude -v /var/run/docker.sock:/var/run/docker.sock

# Custom template
docker sandbox run claude --template my-custom-image

Supported Agents

Docker Sandboxes isn’t Claude-specific. It supports:

• Claude Code
• Gemini CLI
• Codex
• Kiro
• OpenCode

Experimental Status

Docker Sandboxes is currently experimental. The roadmap includes switching from containers in Docker Desktop’s VM to dedicated microVMs for even stronger isolation and better Docker-in-Docker experiences.

Why Both Approaches?

Docker’s container-level isolation and Claude Code’s OS-level sandbox can work together:

• Docker provides the isolated system environment
• Claude Code’s sandbox adds fine-grained access controls within that environment

Think of Docker as the outer perimeter, Claude Code’s sandbox as the inner guard.

Security Considerations

Watch out for:

• allowUnixSockets with Docker socket access effectively bypasses the sandbox
• Some tools requiring specific system access may need to run outside the sandbox
• Windows support is planned but not yet available

The Bigger Picture

Sandboxing isn’t just about convenience—it’s about making autonomous agents viable. An agent that needs approval for every action isn’t really autonomous. By defining security boundaries upfront rather than policing every operation, Claude Code can actually act like an agent while remaining safe.

The 84% reduction in prompts isn’t the goal; it’s a side effect of doing security right.

Sources: Claude Code Sandboxing Docs | Anthropic Engineering Blog | Docker Sandboxes Blog | Docker Sandboxes Docs