Back to Research

agent-manager Puts AI Agents in tmux

agent-manager keeps coding agents in tmux sessions and shows where review, prompts, and stalled panes need attention.

Henri-edmond cross, madame hector france, 1891, 02, landscape painting by Henri-Edmond Cross (1891).
Rogier MullerJuly 31, 202610 min read

agent-manager is YoanWai’s open-source terminal UI for running AI coding-agent sessions inside tmux. It deals with a very ordinary pain: Claude Code, Anthropic’s coding agent, Codex, OpenAI’s coding agent, 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 takeaway is simple: 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 MIT 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.

The trap is treating 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.

The trap is 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 the related training topic: 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.

The trap is 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.

The trap is confusing 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.

Common questions

  • Is agent-manager a replacement for Claude Code?

    No. agent-manager is a tmux-based manager around coding-agent CLIs, including Claude Code. The repository describes support for Claude Code, OpenCode, Codex, Grok Build, and Gemini CLI status detection, while also allowing other CLI tools to run as sessions.

  • Can I use it for claude code pr review?

    Yes, if you keep the scope narrow. The useful path is to let Claude Code produce a small change, open agent-manager’s diff view, leave line comments, and send one consolidated prompt back. It should complement your normal PR review, not replace CI or human approval.

  • Does it handle claude code security review?

    Not by itself. agent-manager can make the changed files and agent state easier to see, but it does not certify security-sensitive code. For a claude code security review, mark risky paths first, require tests or static checks, and keep secrets, auth, migrations, and payment logic under explicit human review.

  • How is this different from just using tmux windows?

    Plain tmux gives you durable sessions, but it does not give you one agent-aware list with live status, grouped projects, pane previews, and a diff comment loop. If you run one agent at a time, tmux may be enough. The manager starts to matter when three or four sessions are active.

  • Do I need Claude skills or CLAUDE.md to try it?

    No. You can try agent-manager with ordinary CLI prompts. Claude skills and concise repository memory become useful when you want repeatable review behavior, but they are not required for the first experiment. Start with visible sessions and a small diff.

Best ways to use this research

  • Best for: Developers already running multiple terminal coding agents who lose time checking whether each one is done, blocked, or waiting on approval.
  • Best first artifact: A one-repo trial note with session names, risky paths, the smallest test command, and the final diff review result.
  • Best comparison angle: Compare agent-manager against your current tmux tabs or GUI agent app by time-to-detect: how long does it take to notice a blocked permission prompt?
  • Best Claude Code fit: Use it with narrow prompts, a small slash command for review, and concise repo conventions rather than large permanent memory dumps.

Further reading

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Related training topics

Related research

Continue through the research archive

Ready to start?

Transform how your team builds software.

Book a 15-minute sync