Author fights AI brain fry from parallel Claude Code sessions with a git ticket queue
The post starts from a familiar scene for anyone who works with Claude Code or Codex in a terminal. You start a task, and because the AI takes time to reply, you start another. The first reply then needs a clarification, a follow-up and a side task, and each wants its own tab. Soon you are hopping between 20 threads (the author's illustration, not a measurement), trying to hold every context in your head. Eventually focus breaks, and you no longer know what you were doing, where you started or where you were meant to finish.
The author notes that many people suggest taking breaks, thinking before typing and limiting scope, then offers a personal experiment instead. The diagnosis is that this way of working has two major problems: sequencing and context. The response is to organise work a bit like a priority queue.
The queue lives in git. Every ticket is a markdown file in the repo, right next to the code it describes, and the state of the board is a committed snapshot. Nothing important lives in a chat window or in the author's head, and if a session dies, the queue is still there.
An agent works the board in cycles. It researches new tickets, builds the ones a human has tagged as safe to build, runs the tests and a browser check, and verifies what is already deployed. For anything touching sensitive code, it builds on a branch and asks first. It never deploys to production; the author does that part.
What the agent cannot do is decide. Everything that needs the author lands in one place called the owner inbox: a script reads the whole board and produces a prioritised list of exactly the items waiting on the author's judgement, such as reviewing a change, answering a question or ruling on a tradeoff.
The reading surface is a Claude artifact: one page, rebuilt from git on every cycle, mirroring the whole board and adding a review page per ticket. Instead of scrolling back through a terminal to reconstruct what a change does, the author opens one link, reads what was built and why, and gives a verdict. The verdict goes back into git, onto the ticket card. The page is only a viewer; git is the record.
The author calls the next step the part that matters most. Take one item, load its context, make a decision or request an action, and close it by putting it back into the queue. That closing is "the whole trick": the ticket stops hanging in memory as something to remember, the context closes with it, and the next item gets full focus, one thing at a time.
The author says it is still exhausting, but not distracting or disorienting. The remaining challenge is the tooling: serving context in a digestible way so that loading a ticket takes a minute and not twenty, and keeping tickets from falling into endless loops while they wait for a ruling only the author can give. The author calls the setup a living organism that keeps being improved, and says it felt like a huge step forward in productivity with AI tools, which is why it was worth sharing.
Key facts
- Tickets are markdown files in the repo next to the code, and the board state is a committed git snapshot, so a dead session loses nothing.
- An agent works the board in cycles: it researches new tickets, builds those a human tagged as safe, runs tests and a browser check, and verifies what is deployed.
- For sensitive code the agent builds on a branch and asks first; it never deploys to production, which stays with the author.
- A script produces a prioritised owner inbox of items awaiting the author's judgement, shown on one Claude artifact page rebuilt from git each cycle.
- The author takes one item at a time and closes it by putting it back into the queue; the post calls this closing the whole trick. The gain is the author's own impression, with no measurements.
Why it matters
Running several Claude Code or Codex sessions at once is a common habit, and the post names its cost: the human becomes the bottleneck, holding many contexts in memory until focus collapses. The proposed answer moves state out of the head and out of chat windows into git, and limits the human to decisions. It treats the problem as one of sequencing and context rather than willpower, which is why it differs from the usual advice to take breaks, think before typing or limit scope.
Who it affects
Developers who drive coding agents from the terminal and open a new tab for every follow-up or side task. It speaks most directly to people who run work in parallel and find themselves reconstructing what a change does by scrolling back through terminal output.
How to use it
The post describes a pattern, not a product. Keep each ticket as a markdown file in the repo beside the code it concerns, and commit the board state. Let an agent cycle through the board: research new tickets, build only those a human has tagged as safe to build, run tests and a browser check, and verify what is deployed. Route sensitive code to a branch with a question first, and keep production deploys manual. Have a script list only the items waiting on your judgement, view them on a single page rebuilt from git, record each verdict back in git, and handle one item at a time. No code, repository, tool name or download is published for the script, the agent cycle or the artifact page.
How solid is it
This is a first-person account of one person's workflow. The post gives no measurements, benchmarks or before/after productivity figures; the gain is described as the author's impression, a huge step forward in productivity. The 20 threads figure is illustrative, not a survey or measured result. No other people's results or independent verification are reported. The post does not say how often the agent cycles run, or which model or agent product runs them.
Risks and caveats
The author admits the approach is still exhausting. The open problems are tooling: serving context in a digestible way so that loading a ticket takes a minute and not twenty (a goal, not a measured result), and keeping tickets from looping endlessly while blocked on a ruling only the author can give. The setup also depends on the human staying the decision point, so the owner inbox can fill with items waiting on that one person. The post does not name who suggested breaks, thinking before typing or limiting scope; it only says a lot of people do.
“That closing is the whole trick.”
— From the blog post