tab A different tool per spawn
Cycle claude, opencode, codex, grok or anything you configured without leaving the bar. The footer shows which one the next enter will start.
Go · tmux · MIT · macOS and Linux
Run every AI coding agent from one terminal.
Everything is one keypress. Start an agent, answer the one that is blocked, open its diff. Never leave the list.
$
brew install yoanwai/tap/agent-manager
space
Five agents in five sentences.
One key starts them all. On a group row
space spawns a new agent there, with your prompt already
embedded and the group's directory already set. No form, no cd, no naming.
The bar clears and stays open, so the next agent is the next sentence. On a session row
the same key answers the agent that is already running.
space Spawn, one sentence each
Type what the agent should do, press enter, repeat. Five agents across three projects cost five sentences and no context switches, and each one starts working the moment it launches.
space Answer in place
On a session row the same key sends your reply into that agent's pane as a user message, so a blocked agent never costs you an attach.
auto They name themselves
A session starts as claude-a1b2 and renames itself once the agent knows
what the work is, so five of them still read as a list of features.
Six states, and for Claude Code they arrive from its own hook events rather than from guessing at the pane. How detection works.
workingMid-turn. Editing, running tests, thinking.
waitingBlocked on you. A permission prompt or a question.
finishedTurn complete, nothing pending.
erroredThe agent reported a failure.
idleAlive at a prompt with nothing to do.
deadSession ended. The row and its history stay.
ctrl+r
Comment a line. The agent gets your notes.
The session's repo, full screen: changed files on the left, the entire file on the right, so an edit reads in context instead of as a hunk. It refreshes while the agent keeps working.
c then C Line comments
Note a line. C flattens every note into one review prompt and drops it in
the agent's pane.
s Four scopes
Uncommitted, versus the merge target, the last commit, or staged.
u Split or unified
Toggle in place, cursor held on the same source line. All review keys.
v
Kill it for the RAM. Revive the same conversation.
The process and the record are separate things, so ending one never costs you the other.
x Kill, keep the row
The tmux session ends and the RAM comes back. The row stays, marked dead, name and conversation id intact.
v Revive, same thread
Relaunches on that exact conversation through the tool's own resume command, not a fresh one.
g A tree, not a list
Groups nest as deep as you want, and reordering sticks across restarts. More.
tab
Five agents out of the box, any other in five lines.
tab cycles the tool the next spawn will use. Live status ships for these:
Claude CodeOpenCodeCodex
Grok BuildGemini CLI+ any CLI
Anything else runs as a session immediately, and earns the same status the moment you describe it. The whole block.
config.toml
[tools.mytool]
command = "mytool"
default_status = "idle"
rules = [
{ state = "working", pattern = "esc to interrupt" },
{ state = "errored", pattern = "(?im)^\\s*error:" },
]The manager registers its own MCP server into every session it spawns, so the agent can drive it back. How registration works.
- renameNames its own session once it knows what the work is.
- review_repoDeclares the repo it moved into, so review opens on the right one.
- review_baseDeclares the branch the work merges into.
- review_modeSets the diff scope, staged just before it commits.
q
Quit. They keep working.
Sessions live on a private tmux server named agentmgr, so they never mix with
the tmux you run yourself and a kill-server on your own socket leaves them
alone. Close the manager, close the laptop: they are still there when you come back.
Not here yet: worktree creation, cost tracking, mouse navigation, agents
that talk to each other. If one of those is what you came for, the
comparison says which project does it.