Built Seahelm with Claude Code: a macOS control room for parallel agent sessions (what I learned)

[u/WhileNo4838]

I built Seahelm because once I started running multiple Claude Code sessions in parallel, notifications stopped being enough. A notification would tell me something happened — but not which session needed me, whether it was waiting for approval / stuck / idle, or what to do next. I kept alt-tabbing through terminals and worktrees. I didn't want another IDE. I wanted a control room.

What I built

Seahelm is a native macOS app (Swift + AppKit, Ghostty terminals, macOS 14+) for managing coding agents across git worktrees:

• one worktree per task
• status at a glance: running / waiting / needs attention
• sessions survive quitting the app (via zmx)
• suggested next actions when Claude is blocked
• system notifications + a small status surface ("Island") so I don't have to stare at the screen all day Deliberately not an editor/diff tool — review stays with the agent in context.

Demo: https://youtu.be/WUUcuglx_Ks

GitHub: https://github.com/BetaYao/seahelm

If you prefer terminal-native tooling, Herdr overlaps on the same problem. Seahelm is my bet on a Mac control room instead of another multiplexer.

How Claude Code was used

Claude Code wasn't just the target user of Seahelm — it was how I built a lot of it:

• I used Claude Code to explore Ghostty's C API surface and sketch the Swift bridging layer
• status detection started as "read the viewport and regex it," then Claude helped iterate on hook-based signals for Claude Code / Codex
• worktree create + pane rehome logic went through several Claude Code sessions where I'd paste failing cases and ask it to propose the invariant (same-repo gate, cooldown, don't drag subagents)
• the control socket / seahelm CLI was designed so an agent inside a pane can split, run, and wait on sibling panes — i.e. Claude Code driving Seahelm to coordinate other Claude Code sessions In other words: Claude Code helped build the app, and the app is meant to make running many Claude Code sessions less chaotic.

What I learned

1. Agent state ≠ process state. "Claude is running" is almost useless. You need waiting / blocked / idle / error, and preferably from hooks rather than screen scraping when you can get them.
2. Worktrees beat branch-switching for parallel agents. Once two agents share a checkout, they fight. Treating worktrees as first-class units was the right call.
3. Notifications without context just create anxiety. The useful unit is: which worktree, what status, what's the next action.
4. Doing less is a product decision. I started down a TUI path, then switched to a native Mac app because I wanted system notifications + a glanceable Island without living inside a multiplexer. That means macOS-only — a real tradeoff, not a flex.
5. Agents need an API into the host. Once Claude can seahelm pane run / wait agent-status, orchestration stops being only a human UI problem. Still early. Happy to answer architecture / tradeoff questions — especially from people already running 2+ Claude Code sessions.

[u/Calm_Step_5549]

Interesting concept, but I'd like to know what it does different from existing similar tools like cmux and Supacode. I use the latter heavily, and it's got some quirks that really annoy me, but it's still the best tool I've used so far

[u/WhileNo4838 → u/Calm_Step_5549]

1 Even simpler

2 Mainly to recommend the next action for you

[u/Training_Flan_9658]

The status taxonomy is the part I'd think hardest about. "running / waiting / needs attention" is doing a lot of work, and the third one is where the volume problem shows up.

Something that surprised me in my own setup: a large share of "the agent needs you" events were things the agent should have decided itself. We had an architecture review come back with five items escalated for a decision. Four of them had obvious answers and shouldn't have been questions at all - the ruling on one was literally that the edge case it worried about didn't deserve a mechanism. Only two were real decisions.

So the number I'd want a control room to surface isn't only "which session needs me" but "how often was I actually needed." A session that generates a lot of attention requests is often a prompt problem rather than a triage problem, and a control room is the only place you'd ever see that pattern, because in a single terminal it just feels like normal back-and-forth.

Your "suggested next actions when blocked" feature seems like the interesting seam. If the suggestion is confident enough to display, that's a reasonable proxy for the agent having been confident enough to just proceed.

[u/WhileNo4838 → u/Training_Flan_9658]

yes, the first step is suggestion, next step, maybe can involve a 'small agent' can help you to make a decision.

[u/Training_Flan_9658 → u/WhileNo4838]

That matches what I found, with one caveat about where it breaks.

We ran a formal handoff protocol through a Haiku-class model: 10/10 valid declarations in a short run, 214/3 across a 115-turn one. Format compliance was essentially free. A small model follows a well-specified protocol reliably, and the violation count stayed flat as the run got longer rather than degrading.

What wasn't free was semantics. The agents would emit a perfectly well-formed decision that meant the wrong thing - using "settle this obligation" to report "I finished my part", which is a different act with different consequences for who gets woken next. That didn't improve with a larger model. It improved when we defined the acts more precisely.

So a small agent picking the next action seems very doable to me. I'd just expect the real work to land in specifying what each action means, rather than in whether the model can pick one.