Agent-Manager Gives Codex a tmux Dashboard

Agent-Manager is a Go terminal UI by YoanWai for running AI coding-agent sessions inside tmux. It deals with a very plain problem: once you have Claude Code, Anthropic's coding agent, OpenAI Codex CLI, OpenCode by SST, Grok Build by xAI, or Gemini CLI by Google running at the same time, tabs stop telling you what is happening. The takeaway is simple: Agent-Manager is interesting because it treats agent work as session operations, not chat history. The codex cli github connection is practical rather than flashy: it gives Codex users a way to keep CLI sessions visible, resumable, and reviewable from one terminal screen.

A tmux TUI is a terminal interface that uses tmux sessions as the durable process layer, so the work keeps running even when the manager view closes. That choice is the whole story here. Agent-Manager is not trying to be an IDE, a hosted agent platform, or a project planner. It is trying to make the messy middle of parallel agent work less invisible.

As of July 31, 2026, the repository shows about 180 GitHub stars, is mainly written in Go, and uses the MIT license. The README says status detection supports Claude Code, OpenCode, Codex, Grok Build, and Gemini CLI out of the box, while other CLI tools can still run as sessions with added tool configuration.

Watch every agent without tab archaeology

Agent-Manager's sharpest idea is boring in the best way: show every agent session in one list, with live status, grouped into a project tree. If you have three Codex branches, two Claude Code experiments, and one OpenCode refactor running, you should not need to attach to six panes just to learn that one is waiting on a permission prompt.

That is why developers paid attention. The pain is not only waiting for code. The pain is losing the state of the work.

The trap is assuming a better model fixes this. It usually does not. A coding agent can be excellent and still spend twenty minutes paused at a shell approval you did not see.

A concrete repo example: imagine a small Next.js app with one agent updating auth middleware, one agent fixing flaky Playwright tests, and one Codex session cleaning up a payment webhook. In a normal terminal-tab setup, the slowest part is checking each pane. In Agent-Manager, the project tree becomes the work queue.

Prompt and revive sessions instead of reopening context

The README describes a few keys that make the project feel like a tmux-native control room. Press space to send a prompt into the selected session's pane, or to spawn a new agent in the selected group. Press v to revive a dead session on its own conversation.

That matters because agent work often dies in small, annoying ways. A process exits. A terminal disconnects. A session reaches a bad stopping point. If the surrounding workflow makes recovery expensive, people stop running agents in parallel.

The trap is treating this as magic persistence. tmux keeps processes and panes alive, but your repository state still needs normal engineering hygiene: clean branches, readable diffs, and a way to tell what changed. Agent-Manager helps you see and route the work. It does not make every agent output safe.

This is also where it differs from GUI-first agentic IDEs. Some developers will prefer a normal graphical app, especially if they want file trees, inline review, and editor-native state. Agent-Manager is for the person who already trusts tmux and wants the agents to meet them there.

Review changed files before replying

The feature that turns Agent-Manager from a session switcher into a coding workflow is diff review. The README says ctrl+r opens a full-file diff of what an agent changed, with syntax highlighting. Comments left on lines can be sent back to the agent's pane as one review prompt with C.

That is a nice boundary. It puts review between agent output and the next instruction. You are not just watching a transcript; you are looking at the repo delta.

The trap is reviewing only the chat. Chat can sound plausible while the diff is wrong. A Codex CLI verification loop should always come back to files, tests, and repository rules.

Here is a small AGENTS.md instruction that pairs well with this kind of loop:

# AGENTS.md

## Verification
- Before reporting done, run the smallest relevant test command.
- If a command cannot run, say why and name the missing dependency.
- Do not change files outside this package unless the prompt asks for it.
- For MCP-backed tools, read before writing unless the task explicitly requires a write.

That instruction is intentionally plain. It gives OpenAI Codex and other agents a local contract: stay inside the package, run the nearest test, and be honest when verification is blocked. If you want more CLI patterns around this, see the related training topic on Codex CLI workflows.

Try it on one repo before changing your setup

The safest test is not a grand benchmark. Pick one small repository and run two real agent tasks in parallel: one mechanical refactor and one test-fix task. For the codex cli github path, start from the official OpenAI Codex repository, confirm your normal CLI login and command flow work first, then let Agent-Manager manage the tmux sessions around it.

Use a repo where you already know the test command. That removes a false variable. If the agent fails, you want to know whether the failure came from the agent, the repo, or the session manager.

A good first experiment looks like this:

• Start one Codex CLI session on a small bug fix.
• Start one Claude Code or OpenCode session on a docs or test cleanup.
• Leave both running while you work elsewhere for ten minutes.
• Return to Agent-Manager and check status without attaching to every pane.
• Open the diff review, leave one line comment, and send it back to the agent.
• Run the repo's normal test command outside the agent before you commit.

This is not a replacement for review. It is a better inbox for agent state. That is also why it sits close to projects like Termic Runs CLI Coding Agents, where the interesting question is not whether a CLI agent can write code, but whether a developer can supervise several of them without losing the plot.

Try-it-safely checklist

Use this note as the handoff receipt for a first Agent-Manager experiment.

The current rough edges are worth naming. The README says worktree creation, cost tracking, mouse-driven navigation, and agents talking to each other are not here yet. If those are central to your workflow, Agent-Manager may feel more like a useful tmux layer than a complete agent desk.

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.

Practical starter checklist

- [ ] Name the Codex artifact first: an AGENTS.md instruction, a Codex CLI verification loop, an MCP boundary note, or a skills handoff.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about codex cli github?

  Start by writing down one visible team rule for Codex, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Codex artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “Agent-Manager Gives Codex a tmux Dashboard.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• agent-manager — source
• OpenAI Developers — AGENTS.md guide
• GitHub — openai/codex
• OpenAI developers: codex quickstart

Next move

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.