What happened
Herdr’s public core page presents herdr-core, invoked through the hc command-line tool, as “a terminal runtime for coding agents.” Its central claim is persistence: programs run in terminals owned by herdr-core rather than by a terminal window. Closing the Herdr application, quitting a terminal, or updating either does not stop the program; the user can later attach to the same running terminal. The page provides installation commands for macOS, Linux, and Windows, and says hc update updates herdr-core while existing terminals continue to run.
The command set is designed around long-running work. hc run starts a command and waits in the style of a shell command, while hc run --bg --name web bun dev starts named background work. hc ls lists running terminals and hc attach web reconnects to one; detaching uses Ctrl+\\. This gives a coding-agent workflow a durable process layer: an agent run, development server, or test task can remain addressable after the interface that launched it has gone away.
Herdr also exposes agent-to-agent control through that runtime. A program can start a helper, provide it work, wait for completion, read its output, and send a follow-up instruction. The source gives a concrete example: a named Codex review process is launched in the background, instructed to report completion with hc send $HC_TERMINAL_ID, then inspected with hc wait and hc read; hc send can steer it further. Herdr says helpers sit under the agent that started them, report back when complete, and stop when their parent stops. Its example describes Claude Code starting a test run and a Codex reviewer, then receiving their reports in its input.
The core can also add a server, VM, or another laptop through SSH and treat their terminals as one list. Status is not inferred from rendered terminal text: programs report states such as working, done, or needs you through OSC 7501, which Herdr calls the open Program Status Protocol. The page says any program that emits that protocol can expose a status, including a custom script. Finally, the desktop Herdr app is only one client of the core. hc schema exposes an OpenRPC schema with streams and live events, and Herdr explicitly positions editor panels, phone apps, and Stream Deck interfaces as possible additional clients.
What the archive adds
This is a new fact on a known story. The earlier Field Note, Herdr Packages Parallel Coding Agents as an Open Runtime, described Herdr’s persistent panes and visible working, blocked, and idle states. The present release adds the public Apache-2.0 core, the hc control surface, SSH-connected machines, an OpenRPC interface, and the Program Status Protocol as the stated status mechanism.
Trend signal
This supports Harness architecture outlives model choice. Herdr’s value proposition is not a proprietary model: it is the runtime contract around processes, hierarchy, reconnection, status, and client interfaces. The page’s Claude Code and Codex example is especially telling because it frames multiple agent products as programs a common harness can start and coordinate.
Why it matters
Teams often begin multi-agent coding with several terminal tabs and informal handoffs. That can work for a short task, but it leaves basic operational questions unresolved: which process is still running, who owns a helper, where its report goes, and whether a closed laptop window terminated useful work. Herdr offers one answer at the runtime layer rather than inside a single model interface.
The practical implication is separation of concerns. A team can choose coding agents independently from the persistent process layer, connect work on another machine over SSH, and build a preferred control surface using the published schema. The source does not prove that this is the best orchestration approach, but it makes a specific building block available for teams whose workflows already depend on long-running agents, tests, reviews, or development servers.
Limits and uncertainty
The source is a product page, not an independent reliability or security evaluation. It does not establish performance under many concurrent agents, resource isolation, authentication and authorization rules for connected machines, or how safely agents should be allowed to launch and steer each other. It also does not compare herdr-core with terminal multiplexers, agent harnesses, or other orchestration systems. The OSC 7501 status mechanism makes a program’s reported state observable, but the page does not show how truthful, complete, or standardized those reports will be across different agent tools.
Skill to build now
Take one existing coding workflow with a long test run and a review step. Define a parent task, a named helper, the completion message the helper must send, and the human condition that means “needs you.” Then test whether the workflow still has an understandable state after disconnecting and reattaching. That exercise is useful whether or not the team adopts Herdr: it turns an informal chain of terminal actions into an explicit operational contract.
Reader takeaway
Herdr-core is an open attempt to make coding-agent work durable and controllable below the chat interface. Its important claim is not that another model can write code, but that agents, helpers, remote machines, and their status can share a persistent runtime with a published control surface.
Open question
Will a common process-status protocol and open client API be adopted by enough coding-agent tools to make the runtime genuinely model-independent?