agent-manager: a tmux control surface for eight coding agent CLIs
The fastest workflow for every AI coding agent. Live status, quick prompts, worktrees, and diff review from one tmux TUI.
At a glance
- What is it?
- agent-manager wraps the agent CLIs you already run in persistent tmux sessions and presents them as one status list with prompt, fork, shell and diff actions. It is a coordination layer, not an agent, and its value depends on how many concurrent sessions you actually keep alive.
- Who is it for?
- Adopt agent-manager if you already run two or more agent CLIs concurrently and lose time switching terminal tabs to find which one is blocked. Do not adopt it if you run a single agent in one directory, or if you need cost tracking, which the README lists as not yet present.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is session sprawl, not agent capability
Running one coding agent is a terminal. Running five is a tab hunt. Each CLI keeps its own conversation state, its own approval prompts and its own idea of whether it is waiting on you. The README frames the pain directly: instead of hunting through terminal tabs to see which agent is done and which is stuck, every session shows up in one list with live status. That is the whole product thesis. agent-manager does not add reasoning, tools or models. It adds an inventory of running agents and a small set of verbs you can apply to any row without attaching to it. The target user is someone juggling several repositories or several models at once, on macOS, Linux, or Windows under WSL2. If your workflow is one agent, one folder, one conversation, the list has one row and the interface costs more than it returns.
A thin layer means your existing logins and MCP servers carry over
The architectural choice that matters most is stated plainly: each session launches your own installed tool as-is, so login, subscription, config files, MCP servers and shipped features carry over exactly as they behave in a plain terminal. agent-manager is not vendoring the agents or proxying their API calls. It is a Go program using Bubble Tea for the TUI, and underneath it is tmux. Sessions live in the am_* namespace, which is why they survive the manager quitting. That namespace choice is also the integration boundary: anything you can express as a tmux session is something agent-manager can host, and the README says other CLI tools can run as sessions even without status detection. The MCP angle runs in both directions. Every MCP-capable session carries tools on launch that let an agent spawn another agent, send it a message, and wait until it is done. That is agent-to-agent coordination routed through the same session table you are looking at, rather than a separate orchestration server.
Status detection is a per-tool ruleset, not a universal parser
Live status is the feature that justifies the list view, and it is bounded. The README names eight tools with status detection by default: Claude Code, OpenCode, Codex, Grok Build, Gemini CLI, Pi, Command Code and Hermes Agent. Everything else runs as a session but shows no live status unless you add a [tools.<name>] block to give it status rules. That is an honest design: status is inferred from CLI output, so it is only as good as the rules for that CLI. It also means a tool that changes its output format can degrade your status column until the rules are updated. If you use a niche CLI, budget time for writing those rules, and treat the default eight as the supported set rather than the supported-plus-everything set.
Getting it running: two install paths and a dependency floor
Homebrew is the short path on macOS and Linux: brew install yoanwai/tap/agent-manager. The README notes the tap installs tmux with it if missing, and that Homebrew runs on git, so both dependencies are covered. The tap now ships a cask, so anyone on the older formula switches with brew uninstall agent-manager followed by the install command above. The script path is curl -fsSL https://raw.githubusercontent.com/YoanWai/agent-manager/main/install.sh | sh. It downloads the latest release for your platform, verifies it against the published checksums, and installs to ~/.local/bin. It then checks for tmux 3.1+ and git and offers to install whichever is missing through the package manager it finds, printing the exact command if you decline. Three environment variables control it: AGENT_MANAGER_INSTALL_DIR for a different target directory, AGENT_MANAGER_VERSION to pin a version, and AGENT_MANAGER_INSTALL_DEPS=1 to answer the dependency prompt up front, with =0 to skip it. Run agent-manager with no arguments to start the TUI. The tmux 3.1 floor is worth noting because it is a hard gate in the script, not a soft recommendation.
The keymap is the product surface, and it is remappable
Almost everything agent-manager does is a keystroke on a selected row. space sends a prompt straight into a session's pane, or spawns a new agent in the selected group. v revives a dead session on its own conversation. ctrl+r opens a full-file, syntax-highlighted diff of what an agent changed, and comments you leave on lines go back to the agent's pane as one review prompt when you press C. f continues a session's conversation in a separate named fork. T opens a shell under the selected agent, or in the selected group, for builds, Git and one-off commands. Inside a session, ctrl+q detaches back to the manager when your terminal and tmux leave it available, with ctrl+\ as an alternate under the same rule; ctrl+r opens that session's diff review and F3 opens its directory in your editor. A [keybindings.session] table in config.toml moves any of those or hands one back to the agent, and [keybindings.list] moves or turns off any action of the manager's own list, with esc and ctrl+c staying as they are. The diff review flow is the most opinionated piece here: reading a diff and writing line comments that land as a single prompt is a different loop from copying a diff into a chat window.
Where it stops: no cost tracking, no mouse, and a nested-tmux caveat
The README states two gaps without hedging: cost tracking and mouse-driven list navigation are not there yet. Cost tracking is the one that bites hardest for anyone running several agents on metered plans, because the list view is exactly where you would want a running total and it will not give you one. The tmux nesting behaviour is the other friction point. When agent-manager runs inside another tmux, you send the inner prefix shown in the session footer and then press d, and if both tmux servers use the same prefix you have to invoke the outer one differently. Detaching also depends on your terminal and tmux leaving ctrl+q available, which is why an alternate exists. None of this is broken, but it is the kind of thing that costs a few minutes the first time and is easy to misread as a bug. If your environment is already a heavily customized tmux setup, test the detach path before you build habits around it.
Compared with plain tmux plus a shell script
The honest alternative is the thing this replaces: tmux itself with a window per agent and a bit of shell to launch them. Plain tmux gives you persistence, panes and a prefix key, and it costs nothing to learn if you already know it. What it does not give you is a status column. You find out an agent is waiting on approval by cycling through windows. agent-manager's differentiator is precisely that inference layer, plus the verbs that act on a row without attaching: space to prompt, v to revive, f to fork, C to submit a review. You can reproduce the session layout in a tmux config file; you cannot reproduce the status detection or the diff-comment round trip without writing a parser for each CLI's output. That is the trade: a dependency on tmux 3.1+, a Go binary, and per-tool rules, in exchange for not cycling windows.
Maintenance cost and what the licence permits
The release cadence visible in the supplied material is roughly weekly: v0.34.0 on 2026-08-27, v0.35.0 on 2026-09-01, v0.36.0 on 2026-09-06, with the last push to main on 2026-09-10. Pre-1.0 version numbers at that cadence mean the config surface can move, so pinning with AGENT_MANAGER_VERSION is a reasonable hedge for a team that does not want to chase changes. The project is Apache-2.0, which permits commercial and private use and includes an explicit patent grant, but it also requires that you preserve copyright and licence notices and state significant changes if you redistribute or modify it. That matters if you fork the status rules for an internal CLI. Nothing here is legal advice; read the LICENSE file and the NOTICE handling yourself if you plan to ship a modified build. The upgrade path itself is cheap: Homebrew users run the usual brew upgrade, and script users re-run install.sh, optionally with AGENT_MANAGER_VERSION pinned.
Editorial conclusion
Adopt agent-manager if you already run two or more agent CLIs concurrently and lose time switching terminal tabs to find which one is blocked. Do not adopt it if you run a single agent in one directory, or if you need cost tracking, which the README lists as not yet present. Before committing, verify that your tmux version is 3.1 or newer, since the install script checks for that floor, and confirm that your tool of choice has status rules either built in or expressible as a [tools.<name>] block in config.toml.
Community notes