claudebox

A sandbox for Claude Code that makes --dangerously-skip-permissions reasonably safe.

Every project gets its own Colima VM on your Mac — its own daemon, images, network, and credentials — so Claude Code can run fully autonomous without touching your Mac or another project's data.

Read the full pitch View the repo

The problem

You want --dangerously-skip-permissions because that's where the productivity is. On a bare Mac, the flag hands Claude your shell, SSH keys, and home directory. In a devcontainer, the shared Docker daemon means one project's Claude can see and docker cp every other project's containers — including their ~/.claude credentials.

claudebox draws the boundary one level up: every project gets its own Colima VM. Different daemon, different network, different context.

Why claudebox

Per-project VM isolation

Each project runs in a dedicated Colima profile (cb-<id>) — its own Lima VM, its own dockerd, its own docker context.

A Claude session in project A cannot see, list, or docker cp anything in project B. Not by policy — by daemon boundary.

Safe `--dangerously-skip-permissions`

Always on inside the container — that's the design. The container can't reach your Mac filesystem; its docker socket points at its own VM; credentials are per-project, not global.

A compromised session still has full run of its own container. It cannot escape into your Mac or another project.

DooD for real test workloads

Claude spins up an API, a database, a headless browser as real sibling containers on the project's VM — native performance, no nested-VM tax.

Every project has a shared network (cb-net) and a reachable VM IP, so multi-tier apps are browsable from your Mac without port collisions.

The edge cases are worked out

Rotating VM IPs self-heal via $CLAUDEBOX_VM_IP. Disk ENOSPC has a runbook. Secrets live in a chmod-600 file, never on the command line.

A published n-tier networking standard means every Claude session in every project builds multi-container apps the same way.