I had Claude Code build a cockpit for its own agents. It took an afternoon.

In my last post, four Claude Code sessions built an Android app in an hour while I watched four terminals scroll. It worked, but watching was the hard part. When one AI session hands work to helpers, you see the helpers start and finish, and very little in between. If one goes off track, you find out at the end.

I wanted the opposite: one conversation with Claude in the middle of the screen, every helper it starts listed beside it with what it’s doing right now, a way to redirect or stop any of them mid-task, and a picture of everything they touched. So I had Claude Code build it, on our own server, in one afternoon. We call it Forge AIOS.

Plan in plain language first

The first message I sent was “don’t do anything yet, I want to plan this out”. We spent the first stretch only talking: what I didn’t like about our first attempt (a ticket queue, which made every request feel like filing paperwork), where it should run, whose account pays for it, and exactly what “steer” and “stop” should mean. Claude asked a handful of questions, wrote the answers into a plan document, and split the work into six phases.

Two choices from that conversation shaped everything. A stop doesn’t kill a helper: it lets the current step finish, then tells it to wrap up and report what it did and what’s left. And a note to a helper is delivered at its next step rather than interrupting it mid-thought. Both are kinder to the work in progress, and both turned out to be simple to build reliably.

While Claude built, I put together a design system for the look: the panelled frame from the Star Trek computer screens crossed with Windows’ flat tiles, in our black and gold. Every screen in this post is built from it.

Read the terms before picking the engine

There are two ways to drive Claude Code from your own software: its developer SDK, or the ordinary Claude Code program run without a terminal. Before writing any code, Claude read Anthropic’s documentation on how each is allowed to sign in. Personal subscriptions are meant for using Claude Code itself; software built on the SDK should use a paid API key. So Forge runs the unmodified Claude Code program, signed in once by me, and never touches the login itself. The first phase existed only to prove that worked in a container on our server before anything else was built on top of it.

Every phase ends with a test it has to pass

The rule for the build was simple: a phase isn’t done until Claude has written an automated test for it, run that test against the real running system, and it passes. Not a mock, not a demo page: the actual server, with real Claude sessions doing real work. After each later phase, the earlier tests ran again.

Along the way I asked for more: limits on how many helpers can run at once (overall and per AI model), adding a helper myself on a model I choose, a page of session rules with defaults, and linking our knowledge graph so the agents can read the company’s history without being able to change it. Each of those got its own test too.

The helper that refused my instructions

The first test of steering failed in the most interesting way possible. A helper was counting through some files when my note arrived: stop counting, read this other file instead. It read the note, then deliberately ignored it. Its reasoning: the message had arrived through the tool system rather than from me, so it might be someone trying to hijack it.

That’s exactly what an AI working on your code should do. A helper can’t tell my note apart from instructions hidden in a file it’s reading, so trusting both would be a security hole. The fix was to make genuine notes provable: every session gets a secret code that only my side of Forge knows, every note carries it, and the helpers are told that only messages with that exact code come from me. The test then checked both halves: a real note redirected the helper at its very next step, and a fake note planted in a file, with the wrong code, was read and ignored.

What else the tests caught

Every one of these passed a quick look in the browser. The tests found them:

• Background commands posing as helpers. Claude Code reports a long-running shell command the same way it reports a helper, so they showed up as phantom agents.
• A conversation leaking into the next one. After starting a fresh session, the old one’s last reply could still land in the new chat.
• “Idle” while working. When a background helper reports back, Claude Code starts a new turn on its own. Forge didn’t notice, showed the session as idle, and handled my next message as if nothing was running.
• Forge tripping its own security rule. When I steered a helper, Forge passed the note on to the main session so it knew why the helper changed course, but without the secret code. The main session correctly refused to believe it.

Not every failed test was a bug in Forge. Several times the test itself was wrong: it expected Claude to run a command one way and Claude sensibly chose another. Telling those apart, and fixing the test instead of bending the product to it, was a real part of the work.

What it does now

• One conversation with Claude per project, streaming as it writes, with an interrupt button.
• A card for every helper: its model, what it’s doing right now, a box to redirect it and a button to stop it, and its full activity when you click it.
• Approvals in the chat or on my phone. Reading files never asks; changing them or running commands always does, unless I’ve allowed that kind of command for the session.
• The files each agent read or changed, coloured by agent, the uncommitted changes in git, and a timeline where every tick jumps back to that moment in the conversation.
• Every code project on the server, each with its own session that keeps running while I look at another.
• Session rules with defaults: which model, how many helpers at once (overall and per model), and which knowledge graphs the agents may read.

Security, because it can run code

A tool that lets AI change code and run commands needs a tight perimeter, so that was treated as a feature, not an afterthought. It only answers on our own network. Everything that can run code sits behind a password, and the very first password can only be set with a one-time code that appears on the server itself. Nothing runs without an approval except reading files. The parts that talk to Claude only accept connections from inside the server, with a secret. And the knowledge graphs the agents read are read only: when I asked Claude to edit one as a test, Forge blocked it.

What I’d tell another team

1. Plan out loud before any code. A short round of questions and answers settled the decisions that would otherwise have been rework.
2. Make every phase prove itself. A test against the real system, written before moving on, caught problems no demo would have shown.
3. When an AI refuses, ask why before overriding it. The helper that ignored my note was right. The fix made the whole system safer instead of weaker.
4. Read the terms first. How a tool is allowed to sign in and who pays decided the architecture.
5. Keep a person on the decisions. Claude wrote every line of code and every test. I made the calls: what to build, what “stop” means, what may run without asking.

This is how we build for clients too: AI does a great deal of the typing, and people own the plan, the decisions, the testing and anything that touches your accounts or your data. If there’s a tool your business needs, that’s the kind of project we like.

Try it yourself

Forge AIOS is now free and open source. On Windows, an installer sets everything up and has you sign in with your own Claude account; there’s also a version for a home server. The code, the installer and a step-by-step guide are on GitHub.