herdrdev/herdr

The core problem herdr solves is embarrassingly common: you hand a coding agent a long task, close your laptop, and come back to find it stopped somewhere in the middle, waiting for input it never got. Herdr attacks this at the infrastructure level rather than at the agent level. It is a persistent background server that owns the terminals your agents run in — not a wrapper around any particular agent, but the substrate beneath all of them.

The session-persistence model is the real mechanism here. Because herdr is the server and the terminals live inside it, closing the lid or dropping the network does not kill the session. You reattach with the same command you used to start it. This is tmux-like behavior, but the README makes clear the design intent goes further than session persistence alone.

What distinguishes herdr from a plain tmux setup is the status layer. Every pane carries a state: working, blocked, or idle. When an agent stalls and needs a human answer, the tool surfaces that rather than leaving you to audit a grid of silent terminals. For anyone running more than two agents in parallel, that visibility difference is significant — hunting through panes to find the stuck one is exactly the kind of friction that makes multi-agent workflows feel more expensive than they should.

The agent-native angle is where it gets more interesting for builders. Agents can drive herdr themselves through a CLI and socket API: spawning panes, prompting other agents, and waiting until a peer is genuinely blocked before proceeding. The README points to an "agent skill" document for this, which suggests the coordination primitives are real rather than aspirational. Agents talking to agents through a shared terminal substrate, with explicit blocked/idle signals, is a meaningful step toward orchestration that does not require a separate orchestration framework.

The tool supports Claude Code, Codex, Cursor, opencode, Grok, and others without wrapping or replacing any of them. It ships as a single Rust binary with no Electron dependency, so it runs inside whatever terminal you already use. Installation is a one-liner or a Homebrew formula. The keyboard model is tmux-style prefix keys alongside mouse support — both treated as first-class rather than one being an afterthought.

The plugin system and marketplace are mentioned but not detailed in the README. That is a surface worth watching: whether the plugin model enables genuinely new pane behaviors or is mostly cosmetic will determine how much of the workflow actually lives in herdr versus around it.

For anyone building with coding agents today, the persistent-session and blocked-state-visibility combination alone justifies a look. The socket API for agent-to-agent coordination is the more ambitious bet.