Close the Window, Keep the Agents: Herdr's Desktop App and herdr-core

First, what Herdr actually shipped

On 29 October 2026, Herdr announced a native desktop app and a new runtime called herdr-core. The desktop app, herdr-core, and the original terminal app (Herdr TUI) are all open source under Apache 2.0. The core idea takes one sentence: terminals and agents live in the core, not in the window — close the app, update the app, even crash the app, and your agents keep running in the background. Only a crash of the core itself, or a machine reboot, genuinely stops them.

The easy misreading here is to treat this as a brand-new product. It is really a split. The original terminal app had its own background server; the new desktop app runs on herdr-core, an independent runtime, and the two do not share running tasks: an agent started in the terminal app will not show up in the desktop app, and vice versa. The terminal app stays maintained, but it and the new app are separate tracks. Get that relationship straight first, and every feature after it falls into place.

My read: Herdr's problem is not "how to run an agent" but "how not to lose track when several agents run at once". One agent is easy to manage: open a terminal and watch it. Three agents — one changing a website, one reviewing the change, one running tests — suddenly leave a person remembering seven or eight things: which terminal belongs to which project, which one waits for approval, which one finished, where the dev server runs, where the test output went, and whether closing the window loses anything. Herdr exists to settle that bill.

Tell the three pieces apart before anything else

First, Herdr TUI, the original terminal app: a single Rust binary that works like tmux rebuilt around agents. Sessions keep running after you close the terminal, and you can reconnect locally or over SSH; since version 0.9, one client can show local and remote machines together. It recognizes agents by watching each pane's foreground process, and its sidebar tells you which agent is working, blocked, done, or idle. Its binary sends no telemetry — the guide states this explicitly — and there is no account and no hosted dashboard; code keeps running on the machine where you started it.

Second, herdr-core, the new runtime, driven by the command hc. It draws nothing: a shell, an agent, or your own program can drive it. It is the desktop app's foundation, and it can also be installed and updated on its own. The app installer fetches the core when it is missing, and the app can help install or update a core it cannot use. Its API is published as OpenRPC, and hc connect carries that protocol over stdin and stdout, including over SSH.

Third, the Herdr desktop app, a native window: a space is one project, usually one repository on one machine; spaces have tabs, and tabs split into panes; the sidebar lists agents that need you. The window only arranges terminals; herdr-core runs them. Install with a one-line script — curl on macOS and Linux, PowerShell on Windows. The Mac build is Apple Silicon, Linux builds are x86-64 and ARM64, Windows is x86-64. Linux needs a desktop session and a working Vulkan driver, which is worth confirming before you start.

Remember it this way: the TUI is "an old house with its own boiler", the desktop app is "a new house on district heating", and the core is the heating station. The new house and the old house each run their own heat and never share. Updating the new house will not freeze its residents — but if the heating station itself stops (a core crash or a reboot), residents still have to restart. That last clause is the boundary most easily hidden by slogans, and it gets its own section below.

The desktop app's most unusual design: the interface is a pile of files

The desktop app's most noteworthy design is that its entire interface is local plain-text files under ~/.config/herdr-app/: an AGENTS.md telling the agent what it may edit, plus settings.json, keys.json, layouts/, mods/, and themes/. You do not wait for the vendor to ship a "board view" or a "chat view": you let an agent edit these files, and changes take effect on save, with no recompilation.

The announcement demo's prompt says it all: "build a herdr mod that shows my PLAN.md next to you as a live checklist with a progress bar and open it beside this pane". The agent edits the app's files, and a plan pane with a checklist and progress bar opens beside the terminal. The shipped layouts are Herdr, Terminals, and Herdr 98; more layouts can be added with one line each to your agent — Board (agents as cards: Needs you, Working, Done, Idle), Chat (spaces look like channels, agents post updates like teammates), Mission (a green mission-control screen), and Pasture (agents as sheep in a meadow; click a sheep and its terminal opens). These are not in the download, each page carries one line to give your agent, and your current layout stays untouched.

This design has two faces. The good one: the interface finally keeps up with how you work, without waiting for a release. The risky one: you hand an agent the power to remodel its own workbench. The guide's own advice is practical: duplicate a shipped layout or mod before changing it, because the app refreshes the shipped copies on start and leaves your copies alone. My addition: put ~/.config/herdr-app/ under your own backup or version control from day one, or the day an agent breaks your layout, you will not even be able to find "what it looked like yesterday".

What herdr-core can do, in a few commands

hc run starts a terminal in the background and names it — say, a Codex review of a file. hc send hands it another sentence while it works, like "also check the tests". hc attach takes that terminal over from any shell, script, or machine, and Ctrl+\ detaches while the program keeps running. An agent in a core terminal can start other agents: children report back with hc send, the parent gets a note when a child needs you or exits, and children stop with the parent unless started with --outlive-parent.

Remote work is worth a mention too: hc machine add registers a machine you can already reach over SSH, and hc run --on runs commands there. Program and files stay on that machine, but your local core lists its terminals beside your local ones. For someone whose main machine is a Mac and whose heavy work lives on a Linux server, that is friendly: one client shows everything, without switching clients between machines.

Status reporting uses a small open protocol, OSC 7501: the program reports its own status, and the core stores the report rather than guessing from the screen. That differs from the terminal app, which detects agents by watching the pane. Both approaches have trade-offs: self-reporting is more accurate but only works if the program cooperates; watching processes is more general but guessing sometimes guesses wrong. In the core, if an agent's status looks persistently wrong, first check whether it reports over OSC 7501 before suspecting the core is broken.

The boundary most easily misunderstood: when work is genuinely lost

The slogan "close the window and tasks keep running" is true — with the second half attached: you closed the window, not the core. Close a single pane or tab and its terminals end; update the core and already-running terminals keep running; but crash the core itself, or reboot the machine, and the programs stop. On return, panes you kept come back as a fresh shell in the last folder. Herdr does not restart the agent or the command that was in the pane — that work has to be started again by you.

That boundary decides where Herdr belongs: it fits "people go home, agents keep running", not "machines may reboot any time". Before putting a long task on Herdr, ask two questions: will this machine reboot or lose power tonight, and if the core crashes, can I resume from the task's middle state rather than from scratch? If you cannot answer those, do not park your only, unrepeatable long task on Herdr alone.

One related note: release builds of the desktop app send usage telemetry, which can be turned off under Settings, then Privacy; the terminal app's binary does not send telemetry. The two products' telemetry policies differ, so write them separately in a team tool list — neither "Herdr sends no telemetry" nor "Herdr sends telemetry" is fully true on its own.

Against tmux, Zellij, and graphical agent managers

Against plain terminal tabs, Herdr adds persistence and agent state: tabs are gone when closed, Herdr sessions remain. Against tmux and Zellij, Herdr adds "understanding what runs inside the pane": to tmux, Codex is just another command — it does not know whether that command is working, blocked, or done, or whether it waits for your approval. Herdr's sidebar exists for that: turning "which agent needs me" into something visible at a glance, instead of clicking into pane after pane to ask.

Against graphical agent platforms, Herdr runs the other way: it keeps the real terminal and persistent-session model, without wrapping the terminal in its own shell or forcing a desktop-only workflow or a remote setup it alone dictates. The price is that Herdr does not supply the higher abstraction: no product-level task orchestration, no complete agent event history, no managed isolated environments. The guide admits this itself: use a shell when one shell is enough, tmux when tmux is enough, and a graphical platform when you need product-level tasks, isolated environments, and a complete event history. Herdr sits in the middle: more agent-aware than a general multiplexer, lighter than a platform.

One more lateral comparison is worth making: cmux, a Mac desktop terminal. The guide's distinction is candid: cmux is the better Mac desktop terminal (native interface, vertical workspaces, notification rings, a built-in scriptable browser), while Herdr is the better terminal-native multiplexer (server-owned persistent processes, semantic agent states, the same interface on a Mac, a remote Linux server, or a small-screen terminal). They can even stack: cmux provides the Mac interface and browser while Herdr owns the persistent local or remote terminal session. When choosing, first ask whether you lack "interface" or "session ownership" — different answers, different tools.

Community reaction: applause with three questions attached

The desktop app reached Hacker News with 364 points and 259 comments — a volume that says it hit a real pain point. But the skepticism in the comments is worth repeating verbatim, because it maps exactly onto evaluation questions. First, money and independence: Herdr took venture funding, so will the tool change flavor later? The official answer is that the runtime stays open — all three repositories are Apache 2.0 — and a license is harder than a verbal promise, though a license guarantees open code, not a roadmap you will always like. Second, telemetry: release builds send it, even if it can be turned off, and some people distrust that regardless — the same point as the previous section, and one to write into internal docs before a team rollout. Third, competition: cmux, Rex, and Tern all work adjacent ground, and Herdr's differentiation is "server-owned persistent processes plus semantic agent state", not a prettier interface. Test that differentiation as an acceptance criterion rather than trusting a launch video.

One more firsthand note from the guide's author is worth borrowing: he runs several agents daily — one changing a website, one reviewing the change, one running tests — and Herdr's value in his hands is "coordination", not "launching". That lens helps you judge whether you are the target user: if your daily agent workflow already contains "coordination" — dispatching work, waiting for results, dispatching the next round — Herdr is built for you. If you still run one agent and watch it finish, its payoff has not appeared yet; coming back when the workflow gets complicated is fine.

Who should try it now, and who can wait

The ready-now profile is clear: you run two or more coding agents daily, you regularly get lost among "which window is which project", or you are tired of an SSH drop or a closed terminal forcing a restart. The payoff is immediately visible: the sidebar shows who waits for you at a glance, closing the window stops being scary, and remote and local tasks appear in one client.

Three groups can wait. First, people running a single agent: one terminal plus one session, and none of Herdr's payoff applies — get the current workflow smooth first. Second, teams with strict telemetry and compliance requirements: the desktop app's release telemetry is on by default, even if it can be turned off, so confirm how the on-by-default window and the data from it are handled before a rollout. Third, anyone who has not yet decided the boundary for "the interface files an agent may change": try it in a small scope first, set a rule for the agent's editing range (say, mods/ only, not keys.json), then widen.

One more background note: in September 2026 Herdr announced a $6 million seed round, led by Bessemer, with Y Combinator and E2 participating, and angels including Tobi Lütke. Funding is not a guarantee of product quality, but it explains how the project can maintain three tracks — terminal app, desktop app, and core — at once. For anyone weighing "will this tool still exist in three years", that is a signal worth a line in the evaluation sheet — but only a signal. What it does in your hands is still the deciding test.

Day one: from install to a first multi-agent session

Before installing, confirm the platform: macOS needs Apple Silicon (Intel Macs build from source), Linux needs a desktop session and a Vulkan driver, Windows is x64, version 10 (1803) or newer. Install the desktop app with its one-line script, then check two things: that Herdr is in ~/.local/bin (or the Windows Start menu), and that the core is installed — the installer fetches it when missing, and the app can help install or update a core it cannot use.

Open the first session like this: create a space for one repository, open two tabs — one running the main agent changing code, one running a review agent checking it; deliberately close the whole window and reopen it, confirming both terminals survive with correct states; then try hc send, handing the working main agent one more sentence and watching it continue without restarting. Finally, run one "destructive" rehearsal on a test project: close a pane and confirm its terminal genuinely ended. Trying that behavior by hand once beats reading the docs ten times, because it decides whether you will dare to close panes casually afterwards.

One habit is worth forming on day one: name every space after its project and every background task with hc run --name. Names are the only way to tell "who is who" in the sidebar. By the time five agents run at once, adding names is already too late — the sidebar will look like five identical windows, exactly when you most need to know instantly which one waits for your approval.

Conclusion: not a stronger agent, but less lost context

The real selling point of the Herdr desktop app and herdr-core is not that agents run faster, but that "finding your agents" gets more reliable: closing the window does not lose tasks, the sidebar shows at a glance who waits for you, the interface can be changed by an agent itself, and remote and local work appear in one client. The boundaries are equally clear: a core crash still stops tasks, the terminal app and desktop app do not share tasks, and release telemetry is on by default and must be turned off by hand.

For daily vibe coding, this tool's significance may be larger than it looks: when one person directs two or three agents, the bottleneck stopped being "is the model strong enough" a while ago and became "does the person still remember what each agent is doing". Herdr treats that bottleneck — not by directing for you, but by making you lose fewer things while directing. Run the day-one checklist above in a small scope first, then decide whether it earns a place in your main toolbox. That order wastes the least time.