agent-manager

A terminal workspace for the coding agents a developer already has installed, and it does not reimplement any of them: each session launches the user’s own CLI, so login, subscription, config files, MCP servers and every feature that tool ships carry over unchanged. Ten are supported — Claude Code, OpenCode, Codex, Grok Build, Gemini CLI, Antigravity CLI, Pi, Command Code, Hermes Agent and Muse Code — each in a persistent tmux session of its own on a private server, all in one list with live status. The list is not a menu you have to leave: space sends a prompt into the selected session’s pane, enter focuses it with the list still on screen, and v brings a dead session back on its own conversation. ctrl+r opens what an agent changed as full-file, syntax-highlighted diffs, where comments left on lines go back to that agent’s pane as one numbered review round. A session can also spawn, message and wait on another, since every MCP-capable session launches with those tools registered. It is Apache-2.0, written in Go on Bubble Tea, and runs on macOS, Linux and Windows under WSL2.

Who built itThe repository’s 647 commits come from 27 accounts, but 563 of them are his; next come 18, a dependency bot at 11 and a coverage contributor at 9. Of the 41 co-author trailers, 13 name a Claude model, and the ones carrying a version are Opus 5 and Opus 5.5 in a million-token context.

1. 01

   Status is read off the pane, not reported by the agent

   Nothing here asks an agent to report what it is doing. The manager polls each session’s tmux pane, captures the text, normalises it and classifies it into one of the states the interface draws — working, waiting, finished, idle or error — with a per-CLI set of rules. That is why internal/status is a 36,736-byte file with 123,149 bytes of tests beside it, and why those rules live in configuration rather than a branch of code: builtinTools is the only source of tool definitions, and it loads on every start, so an edited pattern reaches every install. Two invariants keep it honest. Panes are read through the engine’s plain-text path rather than tmux’s escape-preserving capture, because a running step’s marker blinks: its off frame is a styled blank cell only the escape-preserving capture shows, so a rule matched on it flaps. And the capture is normalised once — status, activity hashes, quoted prompts and input guards read the same result while the preview keeps the original. The rest is per CLI: OpenCode rows need a sidebar cut out of the capture using the composer’s rendered border and grapheme-aware widths; Codex needs a rule that skips a message typed with Enter during a turn, which was being read as the agent’s last reply; Gemini needs that mechanism plus one optional rule, so an approval dialog quotes the question it is asking instead of the prompt echo.

2. 02

   Diff review happens inside the manager, and the comments travel back

   ctrl+r opens a session’s changes as full-file diffs with syntax highlighting, not as a patch: changed lines are shown in the context of the whole file. A reviewer comments on a line with c, and C sends the round back into the agent’s pane as one numbered review prompt rather than a stream of separate messages, and comments already sent stay visible as open or handled. The same review is reachable without the interface, through subcommands that take a repository, a base ref and a scope, and the state of a round lives in a mailbox file under the manager’s directory. The review also follows the agent rather than the launch directory: the list row, the JSON session listing and the review follow tmux’s own record of where the pane is, so a session that used its CLI’s change-directory command is reviewed where it now stands. The verification rules are unusually specific. The suite drives a real tmux server; the variable pointing at the developer’s own server must be unset before running it; the socket directory has to stay short enough that tmux does not silently fall back to the default socket; and killing that server is forbidden. A green suite is explicitly not enough for a change to the interface, the poller or a tool’s status rules: that change is verified by running the binary on its own socket under a throwaway home directory and reading frames back from a real CLI.

3. 03

   A session is the unit, and a worktree is one of its properties

   This is the clearest line between this project and the archive’s other terminal session manager. CCManager is built around the git worktree: the worktree is what it lists, creates, merges and deletes, and its restore deliberately re-runs a session’s launch command without bringing the conversation back. agent-manager starts from a tmux session instead. Each agent runs in a persistent session of its own on a private tmux server named agentmgr, so they never mix with the tmux a user runs, and quitting the manager does not end them. A worktree is a property a session can have: spawning into one is off by default and is toggled on the new-session form, in the quick prompt or in Settings, landing at <repo>-worktrees/<name> on a branch named am/<name>. What is restored is the conversation. v revives a dead session on its own conversation, R restarts it on an empty context with the same name, group, directory and tool, and f continues a conversation in a separate named fork. Each CLI is asked what it supports rather than assumed to be like the others: Hermes and Antigravity have no fork. The worktree plumbing is real, and the instructions record the trap that comes with it — git stash is repo-wide across worktrees, so with several sessions on one checkout a pop lands on somebody else’s work, and the rule is to commit to the branch instead.

4. 04

   Eleven weeks, 65 releases, and a refactor the author filed against himself

   The repository was created on 2026-07-15 and held 1,545 lines of Go, its largest file 266 lines, and one state model with 20 fields. Eleven weeks later its author opened an issue against his own code: 65 releases and 429 merged pull requests on, main holds 43,491 lines of source and 58,355 lines of tests, the state model has 119 fields and 560 methods, and the file holding it has grown from 1,270 to 2,330 lines. The one restructure along the way is dated: on 2026-08-01 a change broke a 1,866-line key file into feature files and gathered the model’s loose fields into sub-structs, taking it down to 54 — after which new features kept landing in the same central files, which is the issue’s actual complaint. Its title asks for the code to be restructured by feature, and the author’s own comment writes out the end state he has in mind: a model of about 25 fields where each feature owns its state, with one services struct holding the configuration, store, tmux driver, hooks and git. His 647 commits run 277, then 216, then 154 by month. The first outside reply links a pull request on a fork, which is where the refactor stands: specified, not done. The archive’s release evidence covers the last twenty, v0.23.0 in August to v0.39.0 on 2026-09-26.

5. 05

   The release note is a data source with a schema

   Pushing a version tag is the only way to ship: goreleaser runs on Actions with two secrets and attests build provenance over the checksums file, and only the repository’s admin role can push the tag. The instructions single out a silent failure mode — without the Arch packaging secret the Arch step skips without failing, so the run still reports success while the package goes stale — and whoever cuts the release is told to confirm from the log that the release, the Homebrew cask push and the Arch push all appeared. What makes this unusual is that the note itself is read by the program. The manager’s messages panel reads exactly the bullets under a Highlights heading and under a Thank you heading; prose in those sections stays on the web page, and only bullets travel. That is why the house style asks for a summary in the author’s own words above them: the generated list of pull requests says what landed, not what is different now. Thank-you bullets name one person each, and the instructions say to cover issue reporters as well as authors, because the generated changelog names authors only and a fix exists because somebody wrote the bug up. Two limits come with the format: a bullet past 120 characters is cut mid-word in the panel, and every entry carries the version it announces, because an unbounded entry shows to every user forever.

6. 06

   A coverage campaign, a review bot, and the author’s own bug reports

   The busiest outside contributor spent late September raising test coverage. One issue is the ticket; eleven pull requests here answer it, each naming the package it lifts and why the package’s coverage did not count: code reached only through end-to-end tests contributes no lines to its own profile. The numbers moved in public — a terminal-escape package from 56 to 75 percent, the hook and clipboard packages past the 80 percent bar, the command layer from 73 to about 84. Asked whether being assigned those pull requests meant work for him, the maintainer answered that assignment is bookkeeping — every pull request is assigned to its author, his included — and that a label, not the assignee, shows whose move it is. Review is partly delegated to a code-review bot whose configuration is 12,142 bytes. He also files his own issues: four of the open ones here are his, two written as bugs with a reproduction — an agent killed with Ctrl-C that takes the launch script down with it on a Linux system whose shell is dash, closing the pane with no relaunch hint and no shell, and a CLI’s change-directory command that moves the agent inside its interface while the process keeps its original directory. Outside work lands: the update route learned to recognise a binary inside a read-only store and print advice rather than write beside it — a fix from packaging this program for a Nix repository.