Prologue: First, Getting Tangled Up by My Own Pile of AI Agents

My recent workflow has turned into this: several AI agents running in the terminal at the same time—Claude Code modifying one project, Codex doing research in another, and yet another one generating content. Multiple projects in parallel, with the terminal as the main arena.

Then came the problem: I had no idea which agent was stuck, what it was waiting for, or whether it had finished. I tried tmux, used it for a while, then dropped it—I’ll explain why below. Later I switched to herdr: mouse selection, agent status, terminal-close recovery—the three things all felt good. But “comfortable” does not mean “optimal.” I have a habit: even when a tool feels good in practice, I still benchmark it against alternatives to see if there’s a better fit.

So I went through four “terminals for managing AI agents” from top to bottom: tmux as the baseline, herdr, codeg, and agent-deck. I pulled the real READMEs, full license texts, tech stack files, and official docs, and tested whatever could be tested. This post is the conclusion.

First, Classify the Species: These Four Things Are Not the Same

tmux manages “terminals”; herdr manages “terminals that run agents”; agent-deck is a “command center for an agent squad”; codeg is an “IDE-style workspace for agents.”

• tmux (2007, C, 48.5k stars): a general-purpose terminal multiplexer with a server/client model and sessions/windows/panes. Detach and reconnect is its signature skill. But it does not understand agents—it only knows processes and grids. My experience using it: open three panes, run three agents, switch between them one by one to see which one is waiting for my approval, entirely by hand.
• herdr (2026, Rust, 27.3k stars): its official wording is “the runtime your coding agents live on.” A background server owns the real terminals; the UI is only a client. Close the client and the agents keep running. It knows which pane contains an agent, and what state that agent is in.
• agent-deck (2025, Go, 705 stars): a TUI that manages all agent sessions, with conductor orchestration plus git worktree isolation. Note that underneath, it still depends on tmux.
• codeg (2026, Tauri, 2.6k stars): a GUI desktop workspace that aggregates every agent’s historical sessions into one searchable workspace, with a full built-in git client and a mobile client.

The Dividing Line: Does It Know When an Agent Is Stuck?

This is the core of the whole thing, and also the dividing line between tmux and the other three.

tmux’s philosophy is “persist terminals, don’t care about their contents.” herdr’s comparison page has a line that says it perfectly: “Multiplexers persist terminals, not agents… tmux sees panes.” Multiplexers persist terminals, not agents; tmux only sees panes.

herdr natively distinguishes five states: idle (finished), working (currently running), blocked (stuck waiting for your input or approval), done (finished but you haven’t looked), and unknown. The state rolls up through the hierarchy—if one agent is blocked, its pane, tab, and entire workspace all show blocked. One click takes you straight there.

Can tmux get this ability? Yes, but it’s all hacks. The ecosystem already has plugins like tmux-agent-status, tmux-ccm, and ClawTab. The idea is to attach hooks to Claude Code, or periodically read the screen with capture-pane, then draw status into the status line. You can get “programmatic” status hints like BUSY/IDLE, but not “semantic” status judgment—it does not know whether an agent is “reasonably waiting on a long task” or “actually deadlocked.” And solutions like tmux-ccm require you to manually add hooks to ~/.claude/settings.json.

Letting Agents Delegate Work to Each Other

The value of multiple agents is not just running them side by side, but having them collaborate. The three tools take different routes:

• herdr: agents drive herdr themselves through the CLI and socket API—the README says: “agents drive herdr through the cli and socket api: they can spawn panes, prompt each other, and wait until another agent is genuinely blocked.” One agent can send a message to another agent’s pane and wait until it is truly blocked before taking over.
• codeg: a lead agent delegates tasks to other agents by mentioning them with @, they execute in parallel, and the results flow back into the main session. This runs through the ACP protocol, which I’ll cover below.
• agent-deck: the conductor is a resident “command agent” that watches all sessions, handles what it can, and escalates to you when it cannot.
• tmux: none of this exists. Delegation means you manually open a pane, manually send a command, and manually read the output.

What Remains After You Close the Terminal?

This is a deeper comparison of “restore after closing the terminal.” herdr’s session.json stores workspace/pane topology and each pane’s working directory. Press ctrl+b q to detach, reopen the terminal, run herdr, and reconnect directly; historical replay restores the screen. tmux can also achieve “the program is still there, the directory is still there, the layout is still there” through resurrect + continuum plugins—but that restores processes, not conversational context. codeg goes a step further and aggregates historical sessions into a searchable workspace, letting you continue in place. agent-deck stores session records in SQLite and supports archiving.

In actual testing, herdr’s config directory was very clean: under ~/.config/herdr, there were only three things: socket, logs, and session.json.

Mobile Remote Control: Only codeg Supports It Natively

If you want to send tasks from your phone, approve permissions, and watch live output, neither tmux nor herdr can do that—herdr can only be controlled by SSH-ing back into your own machine. agent-deck supports Telegram + Slack. codeg is the only one with native support for Telegram / Feishu / WeChat, with approvals directly from the mobile app, plus QR-code pairing with the web service. I already have a mature Telegram path through Hermes, so this is not an urgent need for me right now. But if you need it, “mobile remote control” is codeg’s unique selling point.

Privacy: Landmines I’ve Stepped On, and Ones I Avoid

I care a lot about this part, because I do not accept tools automatically reading or writing my credentials, keys, or proxy configuration files.

• herdr: I grepped through the entire integration module source code and found no reference to ~/.claude.json. Only when you explicitly run herdr integration install claude does it write a status-reporting hook into Claude Code’s settings.json, and it can be uninstalled with one command. In my test environment, the mtime of ~/.claude.json changed, but that was written by the Claude Code session itself in the test environment; herdr’s source code has zero references to it. It is very easy to verify yourself: run stat ~/.claude.json, note the mtime, run herdr, then stat it again.
• codeg: local-first, no telemetry, but it does collect SSH keys and API keys into its own encrypted SQLite database—it does not read your config files, but it does “copy” credentials into its own database. Whether that is acceptable is up to you.
• agent-deck: this is a landmine. Its ACP/MCP integration reads shared auth directories and may also inject them into Docker container environment variables. For anyone who “does not accept tools automatically touching authentication files,” this alone disqualifies it.
• tmux: zero privacy intrusion—it simply does not touch credentials—but for the same reason, it has no concept of permissions, and server-access ACL is not enabled by default.

Hands-on Testing herdr on Local WSL

Rather than talk endlessly, I ran it myself. I installed and tested herdr 0.8.0 in WSL:

• Installation: downloaded the Linux x86_64 binary directly from the GitHub release into ~/bin; one command, no system modifications.
• herdr server starts a headless service and automatically generates ~/.config/herdr/session.json.
• The CLI works across the board: herdr workspace create --cwd /tmp --label test-ws creates a workspace, herdr agent list lists agents, herdr pane list lists panes, and all return normally.
• Memory usage: RSS 16MB. For people sensitive to CPU and memory usage, this is a very comfortable number.
• When no agent is running, agent list is empty and state is unknown—state detection only activates once an agent is running in a pane, which is reasonable.
• Small hiccup: the CLI command herdr agent list does not have a --json flag, which slightly differs from the docs. Minor issue, does not affect usage.

Why This Category Is Taking Off Now: The ACP Protocol

Among the four, codeg is the only one that uses ACP. ACP (Agent Client Protocol) is an open-source protocol initiated by Zed in 2025, designed to standardize communication between “editor ↔ agent.” The editor handles the chat UI, diff preview, and permission prompts; the agent handles reasoning, tool calls, and file edits; the two communicate via JSON-RPC. JetBrains quickly followed, Google joined in by connecting Gemini CLI, Anthropic released an ACP adapter for Claude Code, and OpenAI provided a Codex CLI adapter. On the agent side, Claude Code, Codex, Copilot CLI, OpenCode, Gemini CLI, Cursor, and Pi all support it.

ACP and MCP operate at two different layers: MCP handles “agent ↔ tools,” while ACP handles “editor ↔ agent.” They complement rather than conflict with each other. This also reveals the protocol leanings of the four tools: codeg is betting on ACP, agent-deck uses MCP, herdr uses its own socket API, and tmux can only rely on external adapters.

The fact that the whole “terminals for managing agents” category is exploding in 2026 is no coincidence: demand for parallel multi-agent workflows is rising (Conductor, Emdash, and Superset all center around git worktree isolation for multi-agent work); the terminal has become the home field for agents (Warp’s Agent Mode and Zellij’s zj-agents plugin are both pushing toward “managing agents inside the terminal”). Most fundamentally: when you have several agents working at the same time, what you lack most is not more terminals, but the ability to see at a glance who is stuck. herdr exists to fill that gap.

Who Each One Is For

• People who stick with tmux: old-school Unix users, people who treat tmux as “a daemon for long-running tasks over SSH,” people who refuse to add another binary, people who do not care about agent semantics, and people willing to spend time configuring things. resurrect/continuum already gets “restore after reboot” to about 90 points. If that is all you need, tmux is enough; no need to switch.
• herdr: terminal-first users, parallel multi-agent workflows, people who use the mouse more than the keyboard, privacy-sensitive users, and those mainly using Claude Code / Codex / Hermes. It gives you the foundation of tmux without forcing you to learn tmux’s conceptual baggage.
• codeg: people who want a GUI workspace + full git client + mobile remote control via TG/WeChat/Feishu, and who can accept a desktop app with resident resource usage.
• agent-deck: keyboard-first users who want advanced workflows like automatic conductor orchestration + forked context inheritance + cost tracking, and who do not mind that it depends on tmux underneath. Privacy-sensitive users should stay away.

My Choice

My primary terminal setup remains herdr, and this time the reasons are complete: native status awareness, agents delegating work to each other, terminal-close recovery, mouse-first operation, 16MB memory usage, and no touching my authentication files. The first three are from actual daily use; the last three come from hands-on testing plus source-code verification.

codeg stays on my shortlist as the “mobile remote control” candidate: if one day I need to send tasks and approve actions from my phone, it is the only tool I’ve seen with native support. But it is a desktop app, has the heaviest resident resource footprint, and stores agent credentials in its own database, so I will not keep it running all the time.

agent-deck is out directly because of the privacy issue. tmux stays on servers for long-running tasks; as an “agent manager,” it simply is not that species.

If you also have a flock of AIs running in your terminal, here is one actionable suggestion: first figure out whether you want “the terminal not to die” or “the agent not to die.” For the former, tmux is enough. For the latter, start by trying herdr—do not start with tmux.

Appendix: Research Method and Sources

For this research, I pulled the full GitHub README for each of the four projects, full license texts (entire LICENSE/COPYING files, not just labels), tech stack files, and official documentation pages (herdr.dev/docs, docs.codeg.app). I used the GitHub API to verify star counts / issues / latest releases (2026-08-11), tested herdr 0.8.0 locally in WSL, and cross-checked the ACP protocol and ecosystem using Tavily + Grok dual-engine search. Main sources:

• herdr: github.com/herdrdev/herdr, README / compare / docs/agents pages on herdr.dev, source modules under src
• codeg: github.com/xintaofei/codeg, multi-agent / chat-channels / privacy pages on docs.codeg.app
• agent-deck: github.com/asheshgoplani/agent-deck
• tmux: README / tmux.1 / CHANGES from github.com/tmux/tmux, plus tpm / resurrect / continuum from tmux-plugins
• Ecosystem: Zed (ACP protocol), Zellij, cmux, Warp, Conductor, Emdash, Superset, OpenClaw
• Data: GitHub API hands-on checks on 2026-08-11 (stars / forks / issues / release dates)

The full report, including all data and item-by-item evidence, has been archived. During the research process, I also frequently discussed this on Linux.do and in the Telegram OpenClaw Chinese community; both communities are worth checking out.