agent-manager Puts AI Agents in tmux

By Rogier Muller07.31.26

agent-manager is YoanWai’s open-source terminal UI for running AI coding-agent sessions inside tmux. Claude Code Codex and OpenCode, SST’s terminal coding agent, can all be working while you have no idea which one is done, blocked, or waiting on a prompt. The project is less about replacing your coding agent and more about making parallel agent work observable before review gets sloppy. For Claude Code code review, its most interesting idea is putting the changed diff and the reply prompt next to the live session state.

agent-manager is a Go terminal app that manages tmux-backed agent sessions, shows live status, groups sessions in a project tree, previews panes, and opens a reviewable diff of agent changes. As of July 31, 2026, the GitHub repository lists an Apache-2.0 license, 179 stars, and support for Claude Code, OpenCode, Codex, Grok Build from xAI, and Gemini CLI from Google.

Watch the panes without living in them

The clever part of agent-manager is not that it starts agents. tmux already does that well. The clever part is that it turns many hidden tmux panes into one status surface.

That matters once you run more than one agent against a repo. One pane might be generating tests. Another might be blocked on a permission prompt. A third might have finished fifteen minutes ago and be sitting on a broken build you have not seen.

agent-manager keeps each agent in its own tmux session, so the work can continue after you quit the manager. In the UI, sessions appear in a grouped tree with live status and a pane preview. You can fold groups, reorder them, and inspect what is happening without tabbing through a pile of terminals.

Don't treat this as magic supervision. A live status list tells you where attention is needed; it does not prove the code is correct. In a real repo, use it to find the next thing to inspect, not to bless the result.

A nice small example is a documentation repo with three chores: update install docs, fix a flaky link checker, and refresh screenshots. Running three agents is not hard. Remembering which one asked to edit package-lock.json is the annoying bit. agent-manager puts that interruption where you can see it.

Review the diff before the agent talks again

The feature that makes agent-manager feel more than a pane switcher is its diff review loop. The README describes a key flow where ctrl+r opens a syntax-highlighted full-file diff, line comments can be left on changes, and C sends those comments back into the agent pane as one review prompt.

That is a useful shape for Claude Code review because the review happens against changed files, not against a chat transcript. Chat is where the agent explains itself. The diff is where the work actually lands.

A practical Claude Code PR review flow can look like this: ask Claude Code to make a narrow change, open the agent-manager diff, comment only on the lines that need correction, then send one consolidated review prompt back. If you are also using a project memory file, keep the durable repo rule short, such as: prefer integration tests for router behavior; do not mock the request parser. Do not paste the whole review conversation into memory.

Watch for reviewing too early or too broadly. If the agent has not run tests yet, first ask it to run the smallest relevant command. If the diff touches auth, billing, migrations, or secrets, do not use a conversational review as your only gate. Treat it as a first pass before your normal human review and CI.

This also keeps the workflow close to the habits we cover under Team conventions: make the repo convention visible, make the review artifact concrete, and avoid turning every task into a new permanent rule.

Try it on one small repo

The safest way to evaluate agent-manager is to use it on a small repo with boring chores. Pick something with tests, low blast radius, and a few changes that can run in parallel.

For example, take a small Go service with a README, a formatter command, and a couple of low-risk issues. Start one Claude Code session for a test fix, one Codex session for docs cleanup, and one OpenCode session for a refactor that should not change behavior. The point is not to crown a winner. The point is to see whether the manager reduces terminal archaeology.

Use the source README’s key model as the experiment boundary:

space sends a prompt into the selected session or starts a new agent in the selected group.
v revives a dead session on its own conversation.
ctrl+r opens the diff review view.
C sends collected line comments back as one review prompt.

Before you let an agent touch real product code, write down the permission boundary in plain English. A Claude Code slash-command workflow can stay tiny:

/review-agent-change
1. Inspect the current diff.
2. Run the smallest test command that covers the changed path.
3. List risky files first: auth, payments, migrations, secrets, generated code.
4. Return: what changed, what passed, what still needs a human.

Watch for starting with your hardest repository. Parallel agents make messy work messy faster. If you cannot tell whether one agent’s change is good in five minutes, it is the wrong first test.

Know where it is still rough

agent-manager is a young open-source tool, not a finished operating system for agent work. The README is explicit about missing pieces: worktree creation, cost tracking, mouse-driven navigation, and agents that can talk to each other are not there yet.

Those gaps matter. Without automatic worktrees, you still need to prevent agents from stepping on each other’s files. Without cost tracking, the manager shows activity but not spend. Without agent-to-agent coordination, you are still the scheduler.

The Hacker News reaction around the release also surfaced a fair comparison question: why use this instead of another agent dashboard or a GUI agent app? The honest answer is that agent-manager is most appealing if you already trust tmux and want a small Go binary rather than a server, daemon, or IDE-shaped control plane.

Don't confuse minimalism with completeness. A terminal UI is wonderful when it fits your hands. It is frustrating if you need rich mouse navigation, built-in worktree isolation, or organization-wide reporting from day one.

For a nearby Claude-specific review story, see Claude Code 2.1.218 Backgrounds Reviews. The overlap is review discipline; the difference is that agent-manager’s story is about watching multiple running agents, not a single product feature.

One-repo trial checklist

Copy this into the issue or scratch note you use for the experiment.

Check	What to do	Pass signal
Repo size	Use a small repo or one isolated package.	You can understand every changed file quickly.
Session split	Give each agent one narrow task.	No two agents need the same file at the same time.
Permission prompts	Watch for blocked sessions in the manager.	You notice prompts without hunting through tabs.
Diff review	Open the diff before sending follow-up prompts.	Comments are tied to changed lines, not vague chat memory.
Test command	Ask for the smallest relevant test run.	The result names the exact command and outcome.
Human stop line	Mark risky areas before starting.	Auth, data deletion, payments, and secrets still get human review.

A good result is not that every agent succeeds. A good result is that you can tell which session is waiting, which one changed files, and which diff deserves review next.

Next step

Try agent-manager on one low-risk repo with two or three agent sessions, then judge it by whether you caught blocked prompts and reviewed diffs faster. If it only adds another place to check, keep your current workflow.