harnesslog.dev

Claude Code, AI, and development stories

EN · KO
H
hwangjungmin

Before Docker Sandbox, you had two choices with Claude Code: approve every bash command manually, or run --dangerously-skip-permissions and hope nothing goes wrong. The first kills productivity. The second is exactly what it sounds like — dangerous.

Docker Sandbox sits in between. It uses OS-level primitives (Seatbelt on macOS, bubblewrap on Linux) to enforce filesystem and network isolation. Claude can read and write inside the working directory, access only approved network domains, and nothing else. No permission prompts for safe operations, no unrestricted access either. Run /sandbox and it’s on.

The real difference from --dangerously-skip-permissions: sandbox boundaries survive prompt injection. Even if a malicious dependency tricks Claude into running something nasty, it can’t touch ~/.bashrc, can’t exfiltrate your SSH keys, can’t call home to an attacker’s server. With skip-permissions, all of that is wide open.

That said, the rough edges are real. Docker itself is incompatible with the sandbox — you need excludedCommands to run it outside. Adding an env var means restarting the sandbox and losing your conversation context. Some dev dependencies don’t match the sandbox OS architecture. watchman doesn’t work, so Jest needs --no-watchman. And the escape hatch (dangerouslyDisableSandbox parameter) exists for when commands fail inside the sandbox — which happens more than you’d like.

It’s the right direction. Just not frictionless yet.