The abstraction layer above Claude Code

My Claude Code workflow used to be a Ghostty window full of terminals. One agent would be implementing something, another would be waiting for me to answer a question, and a third would have finished ten minutes ago without me noticing. I would jump between them, run the next command, update the ticket, ask for a review, then try to remember what each one was doing.

Claude was writing the code, but I was still running the workflow. Most of my job had become command one, command two, command three, command four. The sequence only existed in my head. If I closed the laptop or ran out of battery, the processes stopped and so did the person keeping track of them.

gongbox is my attempt to move that job somewhere more permanent. It is a dedicated server with my repositories, worktrees and agent sessions on it. gongbox handles the boring coordination: start this issue, tell me what is running, pass this instruction to the right session, get a separate agent to review the pull request. I can close my laptop and come back from my phone without reconstructing the whole state from a row of terminal tabs.

A Linear issue is the unit of work. It says what needs doing and which project it belongs to. Starting the issue creates a branch and a separate git worktree, then launches Claude in its own tmux session. The worktree matters more than it sounds. Agents can work on different issues in the same repository without sharing an index or trampling over each other's unfinished changes.

I deliberately did not put everything into a new gongbox database. Linear owns the task and its status. GitHub owns the pull request and its checks. gongbox records the attempts: which agent ran, in which worktree, against which commit. The dashboard joins those facts. When they disagree, it shows the disagreement instead of quietly choosing one.

This sounds pedantic until you automate it. A shell command returning zero does not mean the thing you wanted happened. tmux can accept keystrokes that Claude never submits. A pull request can be green while the latest commit has never been reviewed. gongbox reads the result back from the system that owns it before saying a step worked.

Reviews use a second Claude session in a checkout of the exact pull request head. The reviewer cannot edit, push or merge. Its verdict belongs to that commit, not vaguely to the pull request. If the implementation changes afterwards, the old review no longer matches and another one is needed. This replaced another thing I used to manage by remembering which terminal had reviewed which version.

The machine itself is treated the same way. Its setup lives in a private repository with the provisioning scripts, services and tests needed to rebuild it. A fix made only on the live server is not really a fix because it disappears on the next rebuild.

gongbox is rougher than this description makes it sound. I kept adding helpers whenever I found a failure mode, and now some parts overlap or answer the same question differently. I am consolidating that rather than pretending it is finished. But the original problem is solved: Claude Code runs the coding sessions, while the layer above them no longer depends on me keeping four terminals and a ticket queue straight in my head.