herdr: Detachable Terminal Runtime for Coding Agents

Background and Context

Terminal coding agents have multiplied. Claude Code, Codex, Cursor and OpenCode each ship their own command-line interface, and developers often keep several terminal windows open at once. One agent edits the frontend, one runs tests, and a third waits for you to approve a permission. With that many windows, three problems appear. Which agent is stuck? Does a dropped SSH link kill the running task? And when you switch machines, how do you find the right session again?

The classic answer is tmux, which keeps sessions alive. But tmux does not know what an agent is. It sees a stream of characters. herdr targets that gap. It is a single-file terminal runtime written in Rust, and it describes itself as the runtime coding agents live in. It is not another agent, and it does not replace any existing one. It takes over the terminal those agents run in and gives them a stable, observable home that other programs can orchestrate.

The project is hosted on GitHub and has more than 45,000 stars, which suggests the need is common. In the tool landscape it sits between the agent command-line tools and the operating system terminal. The closest description is a terminal multiplexer built for agents, with a scheduling layer on top.

Deep Analysis

What does herdr actually do for coding agents? Its capabilities fall into four groups. The first is detach without interruption. When you close the client or lose the SSH connection, a background service process keeps the terminals running. If the server or the whole machine restarts, herdr restores the saved layout and can resume supported agent sessions. The project is explicit about the limit: the original processes do not survive. What comes back is the layout and the sessions, not the processes themselves. The second is one window for many machines. Local work and saved ssh hosts share a single window, and the agent list is merged. Each machine reconnects on its own, so one host going offline does not drag down the others. The third is state marking. Every pane is tagged working, blocked or idle. When an agent stops to wait for your answer, herdr says so directly, and you no longer patrol windows one by one. The fourth is the agent-native interface. Agents can drive herdr through the command line and a socket API. They can create new panes, send prompts to other agents, and wait until another agent is truly blocked before they act. Multi-agent work then needs no extra orchestration framework, because the terminal itself is the meeting place.

On compatibility, Claude Code, Codex, Cursor, OpenCode and Grok run directly. herdr owns only their terminal and wraps nothing. Interaction follows tmux habits: a prefix key, plus mouse click, drag and split as first-class actions. A plugin system and a plugin marketplace exist. The product is one Rust binary with no Electron, and it runs inside the terminal you already use.

Industry Impact

Getting started is short. Installation takes one curl script, or brew install herdr, or mise use -g herdr. Windows has a PowerShell installer, and prebuilt binaries are on the releases page. After install, you run herdr in your working directory, start a few agents, split panes as needed, and press ctrl+b q to detach. Running herdr again reattaches. A typical case is a remote development host running several agents. You close the laptop in the evening, return the next day, and reconnect. The layout and sessions are still there, and the pane waiting for your answer is easy to spot. The documentation site covers quick start, core concepts, supported agents, key bindings, configuration, session state, multi-machine connections, remote persistence, integrations, plugins and the socket API. A separate guide explains how to add herdr support to your own agent.

The repository also contains AGENTS.md and CONTRIBUTING.md, and it asks AI agents that work on the repository to read them before making changes. For a project whose users include agents, that is a consistent choice. Contributors build with cargo build --release, run unit tests with just test, and run formatting, tests and maintenance checks with just check. For the industry, the point is that herdr treats the terminal as infrastructure for the agent era. Agents used to be isolated command-line programs. Now they run for long periods, cooperate, and spread across machines. That calls for a base layer that knows who is working, who is blocked and who can be woken. For engineering teams, this lowers the attention cost of managing many agents at once.

Outlook

Several risks deserve attention. First, restore does not mean the process stayed alive. Resuming after a restart depends on each agent's own support for session recovery, so teams should not assume it works. Second, the socket API lets agents create panes and send instructions to each other. The permission boundary and the security surface are the user's responsibility, especially across several machines. Third, detecting the state of each agent needs adapters. If an agent changes behavior after an update, the adapter may need to follow.

One more caveat concerns licensing. The license note in the input material was cut off, so a team should check the license terms in the repository before adopting herdr.

Three developments are worth watching. Will the plugin marketplace grow into a real ecosystem? How far will the list of supported agents extend? And can the pattern of agents waiting on each other and prompting each other settle into stable workflows in real projects? The answers will show whether herdr stays a handy multiplexer or becomes a standard runtime layer for agent-driven development.