Sandbox Setup

The idea

Normally, Claude asks for permission before doing things — editing files, running commands, making changes. This is good for safety, but it interrupts the flow.

A sandbox lets Claude work without those interruptions, while keeping your files safe. Claude can experiment freely, and you review the results before accepting them.

Think of it like giving someone a test kitchen to experiment in, rather than your actual kitchen.

Why bother?

• Speed — Claude doesn’t stop to ask permission for every action
• Flow — Long tasks can run without interruption
• Safety — If something goes wrong, it can’t touch your real files
• Review — You see all changes before accepting them

Three approaches

There are three main ways to sandbox Claude Code, from simplest to most isolated:

1. Native sandbox (built-in)

Claude Code has built-in sandboxing that restricts file and network access at the OS level. This is the easiest option.

/sandbox

This opens a menu where you can enable sandbox mode. In sandbox mode:

• Claude can only access your current working directory
• Bash commands run automatically without permission prompts
• Network access is restricted to a controlled proxy

Anthropic reports this reduces permission prompts by 84% in their internal usage.

2. Docker sandbox

Run Claude Code in a container. Good for local isolation without needing a remote server.

docker sandbox run -w ~/my-project claude

First run will prompt for your API key (stored in a Docker volume). Includes Node.js, Python, Go, Git, and GitHub CLI pre-installed.

Useful options:

• -c — Resume your last session
• --dangerously-skip-permissions — Full autonomy mode
• "prompt here" — Start with a specific task

Requires Docker Desktop 4.50+.

3. Remote VM

Run Claude on a cloud VM for complete isolation from your local machine. Most secure, but requires more setup.

Structure:

~/repos/           # Base repos (Claude never works here)
  ├── my-project/
  └── ...

~/work/            # Worktrees (where Claude works)
  ├── feature-x/   # Working on claude/feature-x branch
  └── fix-bug/     # Working on claude/fix-bug branch

Key rule: Claude only works in ~/work/ worktrees, never in base repos.

Any cloud VM works. Hetzner CPX31 (~$15/mo) is a good balance of cost and performance.

Which to choose?

Approach	Isolation	Setup	Best for
Native sandbox	Medium	None	Quick tasks, trusted projects
Docker	High	Minimal	Local development, testing
Remote VM	Highest	More work	Autonomous work, untrusted code

For developers

Git worktree workflow

The VM approach works best with git worktrees. See the Git Worktrees guide for details.

# Create a worktree for Claude to work in
cd ~/repos/my-project
git worktree add ~/work/feature-x -b claude/feature-x

# Claude works in ~/work/feature-x on branch claude/feature-x
# All changes are on that branch, not main

# When done, review and merge (or discard)
git worktree remove ~/work/feature-x

Security considerations

What sandboxing protects against:

• Accidental deletions (git history preserves everything)
• Silent changes (must review diff before merge)
• Blast radius (sandbox can’t touch outside files)

What it does NOT protect against:

• Prompt injection (malicious content could trick Claude)
• Credential exposure (API keys, SSH keys accessible to Claude)
• Malicious code (Claude could write backdoors — review carefully)

Mitigations:

• Review diffs before merging (especially for code)
• Use repo-specific deploy keys, not personal SSH key
• Don’t store secrets in repos Claude can access

---

Official Documentation

• Sandboxing — Running Claude Code in isolated containers
• Security — Permissions, network restrictions, and safety features