ai-spawn
My first step towards a software factory: a retired Claude Code workbench, with the idea now carried forward in envmux and EnoughFactory.
ai-spawn was my first step towards a software factory: a local experiment in making several coding-agent workspaces manageable from one browser. Choose a repository and create a sandbox with its own Git branch and worktree, then interact with Claude Code through a live terminal.
I built the browser dashboard and local orchestration daemon around Docker-backed development environments. The workbench brings together terminals, logs, port forwarding, branch diffs and environment controls. I retired the prototype as the idea developed. The core environment layer now exists in envmux, while EnoughFactory provides the higher-level product.
Highlights
- A Git branch and worktree per workspace
- Persistent terminals and forwarded previews
- Local environment and lifecycle controls
In action
Give each agent somewhere to work
Running several coding agents creates a practical management problem. Each needs a branch, files to edit, a terminal and somewhere to run the application. ai-spawn gathers those pieces into a local workbench, so the browser dashboard becomes an entry point to the environments already doing the work.
Creating a sandbox starts with a repository and creates a new Git branch and worktree. The worktree is a separate working directory backed by the same repository history. A Docker container supplies the development environment, with repository setup hooks for the commands needed to make that project usable.
Keep the terminal close to the result
The sandbox view embeds a Claude Code terminal using xterm.js and a WebSocket connection. A persistent tmux session allows terminal work to continue after the page is closed. Sandbox-specific conversation data is mounted separately so recreating the container can retain the context associated with that workspace.
The same view exposes logs, direct command execution and a Git diff against the starting branch. Those are useful neighbouring views: the terminal explains what the agent is doing, the running app shows the result, and the diff shows what changed. They remain ordinary development tools rather than a separate generated report about the work.
Find the server the agent started
A background watcher detects development servers inside the environment and forwards available ports. The dashboard lists those ports, while manually pinned forwards and stable per-repository ports give previews more predictable addresses. Only one sandbox for a repository owns its stable ports at a time, preventing two environments from claiming the same destination.
This makes the preview part of the workspace's lifecycle. Starting another server should not require hunting through a log for a URL or remembering which container received which port. The implementation keeps discovered services and the controls for reaching them alongside the agent terminal.
Manage environments without losing the branch
The Bun daemon stores workspace records in SQLite and reconciles them with Docker's actual containers. It can restart an environment, identify missing or orphaned containers, and reap idle environments. Restarting preserves the worktree, and tearing down a sandbox preserves it by default, keeping environment cleanup separate from deleting the work.
ai-spawn was an early step towards a software factory, and I retired it as that work developed. The core environment layer now exists in envmux, while the higher-level experience lives in EnoughFactory. This prototype helped establish the problems to solve: creating branches, managing development environments and keeping live access to the work together.
