Kernel

I build with Claude Code every day, and the work stopped fitting in one terminal. I would have three or four agents going on one repo, each in a different tab, and lose track of which one was waiting on me, which one had finished and which one was about to run a database migration I hadn't read.

The tools I tried either hid the agents behind their own account and server or gave me more terminals. I wanted the opposite. My own Claude plan, my own repos, plain files I could read without the app, and one screen that told me what needed me.

So Kernel treats each repo as a room and the agents in its .claude/agents folder as the team. Every status in the sidebar comes from a real Claude Code event. Nothing changes on a timer, so an idle agent looks idle.

Kernel is the Lead in every room. You brief it in a sentence or two, it reads the code in plan mode and comes back with a plan split into tasks, each one named for the agent that will do it. You approve it or ask for changes.

Once you approve, Kernel creates one workspace per task and hands each to the right teammate. The Lead never edits a file in this mode. Its job is to plan and hand out work through its own MCP tools, which keeps one agent from quietly doing the whole job badly.

A workspace is one task. Kernel makes a git worktree on a new branch, copies in the gitignored files the app needs, gives it a free port for its dev server and runs the repo's setup script. Four agents on one repo means four branches and four ports, and none of them touch each other's files.

Inside a workspace you chat with the agent, read the diff file by file, run scripts, and open a pull request when it's ready. Checks show up in the same place. The agent fixes failing checks and answers review comments itself, using instructions Kernel fits to the repo's own PR template and contributing guide. After the merge you archive the workspace and the worktree goes away.

Anything that needs a decision lands in the Inbox. A command an agent wants to run, a plan to review, a question, a pull request that's ready to merge. You can approve a command once or always allow it in that room. Nothing merges by itself.

Before Claude Code runs a shell command, Kernel's guard reads it the way a shell does. Quotes, wrappers, aliases and flag order don't change the answer. Never allow rules, protected branches and the network switch hold in every permission mode, including the one that skips the questions.

Kernel snapshots the worktree after every agent turn. It writes the snapshot through a private copy of git's index, so it never touches your staging area or your branch history. If a turn goes wrong, you revert to an earlier checkpoint and the files go back while the chat stays.

When you want plain Claude Code, you open a terminal tab in the workspace. It runs Claude Code in the same worktree, and Kernel still follows that session through Claude Code's hooks, so its approvals land in the same Inbox.

Four rules shaped the app, and each one is something a user can check.

Claude Code agents built Kernel one Linear issue at a time, working from a canvas of screen designs, with me as the Lead. Every choice someone might later want to undo is written down with its reason, which comes to more than 500 records. The repo keeps them as they were written.

Speed didn't come at the cost of the boring parts. Engine tests run against real git repos and a real hook server, and a fixture mode renders every screen from saved data, so each one can be shot and compared against its design. Releases are code signed, notarized by Apple, and rolled out to a percentage of installs before they reach everyone.

The source is public and the app is a download away, so none of this needs taking on trust. Open the commit history and you can see a signed desktop app go from an empty repo to its ninth release in eight days.

It's also the way I work for clients. Agents do the typing, and I own the plan, the review and the merge. That's how a project ships in weeks rather than months without the code falling apart a month later.