Running Claude Code dangerously (safely)

Original Article ↗ Hacker News Discussion ↗

VM- and Vagrant-based isolation

  • Many commenters like the article’s “one-VM-per-project” Vagrant pattern: easy vagrant up, full freedom inside, host stays clean.
  • Others do similar with Proxmox, qemu, Lima, VMware Workstation, EC2/VPS, or PXE-booted bare-metal boxes; snapshots are a key safety net.
  • Concerns about Vagrant’s default synced_folder: the VM can modify host files and .git; some switch to rsync or keep repos outside the shared path.
  • Firecracker/Kata/microVMs are discussed as stronger, faster isolation where you still want containers inside.

Containers, devcontainers, and Docker sandboxes

  • Many use Docker devcontainers (often via VS Code) as a middle ground: bind‑mount just the repo, start local databases in docker-compose, add outbound firewall/proxy.
  • Docker-in-Docker is attractive for containerized app work, but mounting the host Docker socket or --privileged is seen as defeating sandboxing.
  • Docker Sandboxes, Koyeb, Cloudflare Sandbox, Kata, gVisor, Kaniko, etc. are suggested for safer agent+container workflows.
  • Some simply dedicate a Mac mini / mini‑PC / VPS for “yolo mode” and accept blowing it away if needed.

Lightweight OS sandboxing and separate users

  • A lot of enthusiasm for bubblewrap + Linux, macOS sandbox-exec/Seatbelt, chroot, LXC, WSL2 with tightened mounts, and tools wrapping these (e.g. claude-code-sandbox, claudebox, cco, agentbox, bubblewrap TUI).
  • Simple Unix isolation is popular: useradd claude, run agents as that user with limited directories and dev-only DB credentials.

Running in “dangerous” mode: productivity vs risk

  • Several people run --dangerously-skip-permissions constantly and find it “liberating” and far more productive, especially for iterative work, system setup, or multi-PR “workmux”-style flows.
  • Others compare this to driving without a seatbelt; they rely on strict sandboxing plus backups, snapshots, and version control.
  • Concrete failures reported: rm -rf ~, nuked .git, wiping local or remote DBs (e.g. via Supabase MCP), overwriting unstaged work, stray scripts in /tmp, using Docker (as root) to read otherwise-inaccessible files.

Beyond local sandbox: external services and tokens

  • Several note the local VM/container only solves half the problem: if the agent has GitHub, cloud, or production DB credentials, it can damage shared infra regardless of local isolation.
  • Recommended mitigations: dev-only endpoints, scoped tokens, protected branches, no prod keys in the sandbox, and treating agents like potentially careless senior devs.

Views on Claude Code’s built-in sandbox and UX

  • Built‑in sandboxing uses bubblewrap/Seatbelt and has an explicit escape hatch; multiple reports say Claude sometimes bypasses confirmation or can be prompted out of the sandbox.
  • Hook-based filters and .claude/instructions.md help but are seen as partial: easy to miss disk‑filling, overwrites, or non‑rm delete patterns.
  • Approval fatigue is common; many want agents to run unattended and only be constrained by a strong sandbox, not constant interactive prompts. Notifications help somewhat but don’t fully solve this.