Hotcell

Most developers running AI coding agents locally either expose raw API keys inside the agent process or manually wire git worktrees and hope nothing collides. hotcell runs as a single daemon on your Mac or Linux box and provisions sandboxes — cells — for each agent session. The guided CLI walks through cloning a repo, auto-naming a branch, wiring egress through the gateway, and installing the agent binary, then prints the equivalent one-liner so you can script it. The result is a container or VM with the repo cloned into /workspace, the agent installed, and a scoped token in place of your real credential.

The credential architecture is the sharpest differentiator. On the host, hotcell keys ls shows your real provider key held in the system keychain. Inside the cell, the environment variable resolves to a per-sandbox gateway token — a different string entirely. Prompt injection, a leaked log, or a malicious dependency can read that token; it cannot read your actual API key, and the token is revoked at teardown. Spend caps are enforced per cell at the gateway layer, so an agent that goes sideways stops spending at your limit rather than running up an unbounded bill.

The parallel workflow is where the tool earns its keep: hotcell create -n 5 provisions five cells from the same repo, each on its own branch (feat-1 through feat-5), each with the agent preinstalled, each with its own scoped token and spend cap. Open a terminal per cell, assign tasks, then hotcell rm –all tears down every workspace and revokes every token in one step. The repo on the host is untouched. Isolation tiers — Docker, Firecracker, Apple VZ — let you trade speed for isolation depth depending on how much you trust the code running inside. The tool manages sandboxes; it does not act as an agent, orchestrate tasks between agents, or provide a UI beyond the CLI and home menu.