Herdr brings coding-agent sessions into one terminal

With several coding agents running at once, the next useful action may be as simple as finding the one waiting for a reply. Terminal tabs can hide that small decision inside a larger search: which session was editing, which needed permission, and which has an artifact ready to review? Herdr brings the sessions and their activity into a shared view, making that supervision work easier to organize.

Herdr is an open-source terminal multiplexer and agent runtime. It supplies a place to run and coordinate agents, while the repository and destination systems still supply the evidence for accepting their work. Understanding the difference is especially useful when a status changes, a laptop disconnects or a session comes back after a restart.

Several agents, one place to find waiting work

Consider two hypothetical coding sessions that both become idle. One has produced a patch with passing checks. The other is sitting at a permission prompt after a partial edit. The shared view can help bring both to the operator’s attention, but accepting their work requires different next steps. Session status locates the waiting agent; the repository diff, checks and any destination changes show what that agent actually completed.

The project overview describes workspaces, tabs and panes inside a terminal, with a background server owning sessions and a client displaying them. It supports existing coding agents including Claude Code, Codex and OpenCode, and publishes the runtime under Apache 2.0. This article examines documented behavior; it is not a hands-on performance review.

For a runbook review, the shared view can put the agent’s findings beside a terminal used to inspect the relevant configuration. Herdr provides the workspace and status signals; the engineer can use the second pane to follow file references and assess the proposed correction.

The findings can name the configuration revision and file references behind each proposed runbook correction. That gives the engineer something inspectable and lets the trial distinguish time saved finding a session from time spent checking its answer.

How Herdr derives an agent’s status

Herdr identifies supported agents and classifies activity using the available integration. Without complete lifecycle hooks, it examines the foreground process and terminal evidence against detection rules. Other integrations report lifecycle events directly. The agent detection documentation explains which source has authority, an important detail when deciding how much to infer from the display.

Installing an integration does not automatically make every status event-based. The integration roles document Claude Code and Codex reporting session identity for restoration while activity still comes from screen detection. Pi and OpenCode can use lifecycle reporting. The useful question is therefore how the particular agent being run signals the states the operator cares about.

Return to the two idle sessions. A permission prompt, failed authentication and a finished answer can all look like inactivity at a glance. Testing them separately shows whether the sidebar directs attention appropriately. It also explains why a status should not silently become an acceptance rule.

In the CLI, done means the agent is idle and its completion has not yet been marked seen; it does not certify the result. unknown exposes uncertain classification. These distinctions in the automation documentation make the display more useful when its interpretation stays narrow.

For the runbook review, done is the cue to open the findings against the configuration revision they name. The engineer still needs to check whether each proposed correction follows from those files. The display has found the waiting work; the repository supplies the evidence for accepting it.

Which machine is still doing the work?

The server/client split lets a terminal client disappear while the server continues owning sessions. Under remote access, the remote machine owns the panes and sends their terminal content to the local client over SSH, as described in the remote access guide. Knowing the execution host answers the practical question of what happens when the viewing laptop closes.

If the remote host keeps running, disconnecting the laptop does not by itself stop that work. If the laptop is the execution host, ordinary sleep suspends it. A persistent-looking view cannot change which computer owns the process, so choosing that host is part of setting up the workflow.

Recovery also has several meanings. Detaching keeps live processes; a full server restart restores layout after the original processes are gone. Optional screen history can return recent output, and supported integrations can resume agent conversations. The session-state documentation describes these separate paths.

Suppose, as a hypothetical extension, the agent submitted a change before the restart but lost the response. The restored conversation can truthfully show an unresolved request while the destination already contains the change. Inspection of current destination state is the next useful action; replaying the request from conversation history could apply it twice.

Consequential work therefore needs a recovery record outside the restored view: target, approved action, artifact or operation identifier and independent verification. The production write-access article develops that responsibility. Terminal history helps reconstruct what was seen, while the destination establishes what is true now.

Detaching and restarting preserve different things

Read diagram description

With the execution host and Herdr server still running, detaching leaves the original processes alive. A full server restart restores layout, not those processes. Optional screen history and supported conversation restoration preserve other state; verify current files and destinations before repeating an uncertain action. Diagram labels: Client detaches: Server and execution host remain running; Full server restart: Original pane processes stop; Reattach to live work: Verify the expected process continued; Restore saved layout: History and agent resume depend on configuration; Inspect current state: A restored view or conversation does not certify task success.

Task identity outlasts a terminal pane

Herdr offers separate controls for panes and recognized agents. Automation can create a workspace, start an agent in an available shell pane, submit a prompt and read its response. Creation commands return identifiers, which a script should retain rather than predicting pane numbers. That makes the relationship to the created object explicit.

A wait for an agent state still needs context about the request it is waiting on. Herdr’s automation contract says waits do not track individual turns, and a timeout does not prove that input was never sent. Reading the current agent state before retrying helps avoid a duplicate prompt that would otherwise create another round of work.

For the runbook review, assign a task identifier outside the session and have the artifact name both it and the repository revision examined. A review can finish correctly and later become outdated as code changes. Reopening its terminal does not make the reviewed revision current.

Concurrent editing needs similar explicitness. Two panes aimed at one checkout share the edits visible there. Separate Git worktrees or another deliberate isolation mechanism are appropriate when independent changes are intended. Organizing the terminals alone does not isolate the files.

The runbook reviewer also needs only the material and output location required for its job. A deployment command appearing in the runbook is not a reason to grant deployment authority. The operational skills guide explains how to make those limits enforceable through tools, independently of the convenience of running another pane.

A runbook comparison as the first Herdr task

Use a disposable checkout and configured coding agent, installing Herdr through the official instructions. Record both versions and choose a non-production task whose output can be checked. That makes later differences explainable if an agent or runtime update changes the experience.

The quick start launches Herdr from a project directory and runs the agent in a pane. Detaching uses Ctrl+B followed by Q; running herdr again reattaches. A pane’s context menu can split it to provide a second terminal for comparison.

# In your disposable project directory:
herdr

# Inside a Herdr shell pane, start your configured agent:
claude

A bounded request could ask the agent to compare the runbook with the checked-out configuration, write findings with file references and identify anything it cannot verify. A second pane can hold the operator’s own inspection or a separate review. The task now has enough structure to show whether the shared view improves supervision without assuming the findings are correct.

1. Observe where attention goes. Compare ordinary completion with a request for approval and check that the displayed state helps locate the appropriate pane.
2. Detach while work continues. On reattachment, inspect the expected process and output. The workspace name alone cannot establish continuity.
3. Test restart separately. Record what is running in the disposable session, restart the server and compare what returns with the documented recovery paths.
4. Review the actual findings. Check references and conclusions against the named revision, preserving missed and unsupported findings.
5. Count the supervision work. Note time spent finding waiting sessions and rebuilding context, alongside the time needed to assess the artifacts.

Optional pane history is disabled by default because terminal output can contain sensitive information. Decide whether retaining that output fits the task before enabling it; the persistence documentation explains storage and restoration. More history can aid reconstruction while creating more material to protect.

Herdr is useful in this runbook trial when its shared view reduces the time spent finding waiting sessions and rebuilding their context. Count that supervision benefit alongside the work required to check the findings, and keep the separate restart exercise’s resume and reconstruction costs visible. If unreliable findings dominate, improve the task, evidence or acceptance checks before adding more agent jobs. Disposable exploration can use lightweight review; shared-code and production changes still need evidence proportionate to their consequences.