Why We Built ClusterCode: The Problem with Running AI Agents Unattended

If you use Claude Code, you know the flag: --dangerously-skip-permissions. OpenAI Codex has --dangerously-bypass-approvals-and-sandbox. GitHub Copilot has --yolo. The names are intentionally alarming — they are the manufacturer's warning label.

These flags exist because AI agents need to execute commands, write files, and interact with tools to be useful. But without them, the agent stops every few seconds to ask "Are you sure?" — which defeats the purpose of automation.

The industry's current answer is: just disable the safety checks and hope for the best. This is fine for a quick demo. It is not fine for a production engineering team running 10 agents simultaneously on a codebase that deploys to production.

The risks are real. An AI agent with unrestricted shell access can run rm -rf, push force to main, leak environment variables, or make network requests to arbitrary endpoints. Prompt injection via GitHub issues is a documented attack vector. Corporate compliance frameworks like SOC2 and HIPAA cannot accommodate unrestricted agents.

We built ClusterCode because we realized the solution is not better permission systems — it is better isolation. Each agent runs in its own DevBox with only the repository clone, declared dependencies, and scoped environment variables. A security profile — Open, Standard, Strict, or Offline — governs network egress, filesystem access, and dropped capabilities. The DevBox is disposable. If an agent runs a destructive command, it destroys its own sandbox — not your development environment.

With ClusterCode, --dangerously-skip-permissions is safe to use because "dangerously" stops being dangerous. The blast radius is a DevBox that was going to be deleted anyway.

This is not a theoretical improvement. It is the difference between running one agent nervously in a terminal and running fifteen agents in parallel while you review their pull requests over coffee.