Agent Manager
One tmux TUI that puts every AI coding agent in a single list with live status, quick prompts, and diff review.
README claims a private tmux server (agentmgr) and checksum verification in install.sh; the surface looks restrained, but the snapshot contains no Go source to confirm actual behavior, so only a base score. The installer prompts before installing dependencies (preset via AGENT_MANAGER_INSTALL_DEPS), giving documented but unverifiable confirmation — 1. Data flow transparency is decent: am_* namespace, isolated socket, external access path all documented — 2. No sensitive-data documentation despite agent sessions carrying logins and subscriptions — 1. Dependency security: CI runs govulncheck, gitleaks, shellcheck, with third-party Actions pinned by SHA; evidence is solid — 2 (no dependabot/renovate or dependency-update policy, so not full). External effects are explicit: worktrees, am/<name> branches, MCP-based agent spawning — documented, 2. Rollback is thin: only brew uninstall and a version-pinning variable; no session/config rollback — 1. Attribution: unverified publisher, brand badges but no NOTICE or copyright line — 1.
The README is internally consistent; key tables, install text, and naming (am_*, agentmgr socket) agree — 2. Dependency availability is well covered: tmux 3.1+, git, multiple package managers, WSL2, version pinning — 2. Failure messaging is only documented for the installer ('printing the exact command when you decline'); runtime error handling cannot be verified without source — 1.
Audience and scenarios are very clear: developers running multiple AI coding agents, with each supported CLI named — 3. Boundaries are stated ('Not here yet' list; beta features flagged) — 2. Trigger precision: key bindings are specified per context (focused, full-screen, nested tmux) and remappable; detailed but descriptive, not verifiable rules — 2. Environment fit is thorough: macOS/Linux/WSL2, nested tmux handling, OS theme following — 3.
Information architecture is excellent: README → docs/usage.md → docs/configuration.md → docs/install.md plus a docs site — 3. Install notes cover Homebrew, curl script, Arch, mise, go install, prebuilt binaries, WSL2, uninstall/upgrade — 3. Naming is stable: module path, am_* prefix, agentmgr server name — 2. Examples exist (key tables, usage snippets) but no FAQ section — 2. Known limitations are stated (beta, unimplemented features) — 2. Full Apache-2.0 LICENSE matching README and badge — 3. Versioning: a --version command and release flow exist, but no CHANGELOG in the snapshot — 1. Maintenance: CONTRIBUTING.md, SECURITY.md private advisories, Discussions — 2.
Output usability: diff review with syntax highlighting, per-line comments, numbered review rounds, open/handled tracking — well described, 2 (unverified by execution). High marginal value: aggregates status/quick prompts/worktrees/diff review in one TUI, directly solving multi-agent context switching — 3. Cost-benefit: thin layer reusing existing CLIs and subscriptions; only tmux+git required; reasonable, though RAM and agent-run costs are unquantified — 2.
Claims are traceable: badge data is generated by the badges workflow and pushed to a badges branch; install.sh behavior is enumerated; docs links are explicit — 2. Cross-source corroboration is weak: the snapshot holds only README, LICENSE, go.mod, and CI files — no source, tests, or doc bodies to cross-check performance and feature claims; star/trendshift badges are unverifiable — 1. Fact/inference separation is acceptable: beta status and unimplemented features are clearly tiered — 2.
- This is a static review; the snapshot contains no Go source or test files, so all README claims (private tmux server, checksum verification, session isolation) are unverified at the code level.
- Agent sessions carry user logins, subscriptions, and MCP server configs; the project documents no sensitive-data isolation — assess before running agents in untrusted repositories.
- The installer uses a curl|sh pattern; even with checksum verification, download and review install.sh before executing.
- No CHANGELOG; evaluate release notes yourself before upgrading.
- MCP capability lets agents spawn and message each other, forming agent chains — confirm permission boundaries at each hop.
- Publisher identity is unverified by the registry (unknown, not suspicious); perform independent supply-chain review before enterprise adoption.
What does this agent do, and when should you use it?
agent-manager is a Go/Bubble Tea terminal UI that runs on top of tmux to manage multiple AI coding agent CLIs side by side. It detects live status for Claude Code, Codex, OpenCode, Grok Build, Gemini CLI, Pi, Command Code, and Hermes Agent, with each tool in its own persistent tmux session (am_* namespace, dedicated agentmgr server). Sessions appear in a foldable project tree, so you can see at a glance which agent is done and which is stuck. Pressing space sends a quick prompt straight into a session, ctrl+r opens a full-file diff review where line comments are sent back to the agent as one numbered review round, and v revives a dead session on its own conversation. Agents can delegate to each other via built-in MCP tools, and sessions can run in isolated git worktrees on am/<name> branches.
On launch it starts a private tmux server (agentmgr) and runs your already-installed agent CLIs as-is inside per-tool sessions, carrying over your login, subscription, config files, and MCP servers. It detects each session's status continuously and displays them in a project tree you can fold and reorder. Space sends a quick prompt into the selected session's pane or spawns a new agent in the selected group; ctrl+r opens a syntax-highlighted full-file diff where c comments a line and C sends all comments back as one numbered review prompt. T opens a shell under the selected agent for builds and git commands; alt+w or the new-session form creates a git worktree (<repo>-worktrees/<name>, branch am/<name>). f forks a session into a named fork continuing its conversation. Status detection extends to other CLIs via a [tools.<name>] block in config.
- Developers running several coding agents in parallel (e.g. Claude Code and Codex at once) who need one view of which is done and which is stuck
- Maintainers reviewing agent output: open diffs with ctrl+r, annotate lines, and send a complete review round back in one keypress
- Teams wanting agent-to-agent collaboration: via MCP, one agent spawns another, messages it, and waits for completion
- Developers who need isolated copies of a repo per task: sessions run in their own git worktree on an am/<name> branch
- Users who still need builds and Git commands alongside agents: press T for a shell under the selected agent or group
- Users whose session died or timed out: revive it on its own conversation with v, or restart it on an empty context with R
What are this agent's strengths and limitations?
- It is a thin layer, not a wrapper: your login, subscription, config files, and MCP servers carry over exactly as in a plain terminal
- Structured diff review is a differentiator: full-file context, syntax highlighting, and line comments aggregated into one numbered review round sent back to the agent
- Sessions run on a private tmux server (agentmgr), survive the manager quitting, and never mix with your own tmux
- One tool covers the mainstream agents — Claude Code, Codex, OpenCode, Grok Build, Gemini CLI, Pi, Command Code, Hermes Agent have status detection by default, and any other CLI can be added via [tools.<name>] config
- Hard dependencies on tmux 3.1+ and git; the runtime boundary is macOS, Linux, and Windows-under-WSL2 only
- No cost tracking and no mouse-driven list navigation yet — both are explicitly listed as not shipped
- It manages agents but is not an agent: with no installed agent CLIs there is nothing to manage
- The →/← step-in/step-out navigation is in beta and must be validated in Settings
How do you install or deploy this agent?
On macOS/Linux via Homebrew: brew install yoanwai/tap/agent-manager (installs tmux and git if missing). Or with the install script: curl -fsSL https://raw.githubusercontent.com/YoanWai/agent-manager/main/install.sh | sh — it downloads the latest release, verifies checksums, installs to ~/.local/bin, and checks for tmux 3.1+ and git. Set AGENT_MANAGER_INSTALL_DIR for another directory, AGENT_MANAGER_VERSION to pin a version, AGENT_MANAGER_INSTALL_DEPS=1 to auto-install dependencies. Windows requires WSL2. Other paths (Arch Linux, mise, go install, prebuilt binaries) are documented in docs/install.md.
How do you use this agent?
Run agent-manager to start the manager. Press n to create a session (name, tool, directory, optional starting prompt, group); space sends a quick prompt to the selected session or spawns a new agent in the group; enter focuses a session and keys go straight to the agent; ctrl+r opens diff review (c comments a line, C sends a numbered review round); x kills a session to free RAM, v revives it on its own conversation, R restarts on an empty context; T opens a shell; ? shows the key map for the current screen; s opens Settings (default tool, theme, list density, review layout, desktop notifications). Sessions live on the dedicated agentmgr tmux server and survive the manager quitting; reach them from a plain shell with tmux -L agentmgr ls and tmux -L agentmgr attach -t am_<id>. Keybindings are configurable via [keybindings.session] and [keybindings.list] in config.toml.