commit 1a1c16d 2026 AI & automation
CCC: Claude Code Container – Sandboxed AI Agent Workflow
My own Auto mode, built before Claude Code shipped one. The agent runs unrestricted inside a Docker container, and every call out to the host passes a Haiku risk check, with an approval popup for anything that fails it.
Between YOLO and friction
Before Auto mode, Claude Code offered two defaults, both bad. Running Claude Code with --dangerously-skip-permissions ("YOLO") lets the agent move fast, but it has unrestricted access to your filesystem, network, and shell the moment it decides to use it. Running with the default permission prompts keeps you safe but turns routine agent work into a steady tap-tap of approvals. The right point on that spectrum depends on what the agent is actually doing — implementing a plan you already reviewed is not the same as researching the open web where prompt injection is a real concern.
Container is the blast radius
Claude Code runs inside a Docker container (Ubuntu-based, auto-updating) with the YOLO flag set. Inside the container, the agent has whatever it needs — filesystem, network, shell — and doesn't have to ask. Outside the container, it has exactly one edge, and that edge is gated.
Path parity. Project files are mounted preserving their exact host paths, so there's no translation layer between what the agent sees and what exists on the host. /Volumes/Projects/foo is the same path inside the container as outside it.
Config parity. Claude's own configuration directory is mounted in as well, so hooks, slash commands, and preferences match the host. Moving between a host session and a container session doesn't change the agent's behavior.
host-exec with a Haiku check
The only way the containerized agent reaches the host is through a custom MCP server called host-exec. Every call flows through a two-stage gate:
Stage one — AI risk check. A Haiku model evaluates the command against the working context and conservatively auto-approves low-risk operations (reads, lookups, benign tooling). A little latency, a lot of friction removed.
Stage two — UI popup. Anything that doesn't pass the AI check pops up a native approval dialog with the full command, a threat-score summary, and two buttons: approve, or deny with a reason the agent will see. The reason matters — it lets you push back without killing the run.
One toggle, two modes
The approval loop is the right default, but it's not always the right state. A toggle flips auto-approve on or off for the current container — either via a slash command inside Claude or through a small browser page on localhost. Implementing a reviewed plan? Auto-approve everything. Researching online where prompt injection is a live risk? Flip it off and let the gate catch every host call.
Fleet, MCP routing, small details
Many CCCs at once. A local dashboard lists every running container on its port (3100–3115) with its own auto-approve toggle. Different projects run in parallel without stepping on each other.
MCP routing. Some MCPs live inside the container; others run on the host and are exposed to the containerized agent via mcp-proxy, a small stdio-to-HTTP bridge. Same tool surface either way, but no need to install host-side tooling inside every container.
Configuration. The current working directory is mounted automatically; additional paths can be added via a .cccrc file. Path parity between host and container turned out to be a practical win worth the small setup cost.
Sound hooks. Claude Code event hooks that play sounds use a CLI wrapper that plays directly on the host — or, when running inside the container, routes the sound playback through host-exec. One hook config, correct behavior in both places.
Worth noting: this isn't a foolproof agent-safety solution. It's a more practical point on the spectrum between no supervision and Claude Code's default permission system. For my day-to-day work, it was the right balance until Claude Code caught up.
Then Auto mode shipped
Anthropic later added Auto mode to Claude Code, and in August 2026 made it the default. A classifier reviews each tool call before it runs, lets the safe ones through, and blocks anything destructive or aimed outside your environment. That is the same idea as CCC's Haiku gate, built into the product, with nothing for me to maintain. These days I run Auto mode on the host for most work and start a CCC container only occasionally.
What CCC still does better is isolation. Auto mode's classifier makes a judgment call on the host, so when it gets one wrong, the action runs with full access to the machine. Inside CCC, a wrong call can only damage the container and the mounted paths, and the host stays behind the gate. For riskier work, such as browsing the open web or running unfamiliar code, that harder boundary is still worth the setup.