Herdr Desktop: It's Been a Long Time Coming, and It's Finally Here

It’s been a long time coming, and it’s finally here.

Herdr has a desktop app. I’ve been using it, and working with my agents is substantially better now. Not because I suddenly needed permission to use a mouse. Because keeping track of the work takes less work.

Back in July, I wrote about what Herdr added that tmux never had: a way to know whether an agent was working, finished, or waiting for me. I was reading the architecture then, not reporting hands-on experience, and I said that an interesting design was not yet a reason to migrate.

This is the follow-up. The interesting design has become something I want open while I work.

I still care about the same question: what recurring annoyance does this remove? For me, the desktop app removes enough checking, switching, and reconstructing context that the difference is obvious. I spend less time finding the agent I need and more time dealing with what it actually needs from me.

That is a much better reason to install something than a prettier screenshot.

The terminal was not the problem

I live in terminals. That has not changed.

My agents are terminal programs. So are my shells, editors, test runners, and most of the tools I trust. I don’t want a desktop app that replaces those with a chat interface and then spends the next year reimplementing half the capabilities it threw away.

Herdr doesn’t do that. These are real terminals, with the programs I already use running inside them. The desktop gives that work a place: projects, tasks, panes, agent state, files, changes, and remote machines.

With a few agents running, the annoying part is rarely starting another one. It is remembering which task lives where, noticing when something needs approval, and getting back to the right context without visiting everything else first. A terminal full of output is not automatically an overview of the work.

The desktop makes that overview much easier to keep. The win is not more agents. It is less attention spent managing the agents I already have.

First, this is not the old TUI in a window

This distinction matters if you read my earlier post or already use Herdr.

There are now three names worth separating:

Herdr TUI, the original terminal application, with its own server.
herdr-core, the runtime that owns the new app’s terminals and agents. Its command is hc.
herdr-app, the native desktop window that presents and controls that work.

The desktop is a separate program built on herdr-core. Agents started in the old TUI do not automatically appear in the desktop app. They live in different runtimes. The welcome flow can help bring settings and keybindings across; that is not a live session migration.

The app uses Rust and GPUI for a native GPU-rendered interface, not an Electron window. Its mods are JavaScript, but they describe native UI elements, not a web page. Useful architectural context, not a benchmark claim. I am not attaching invented RAM numbers to the word “native.”

This post covers Herdr Desktop 0.1.11, the release available as I write on November 1. The README and changelog are worth keeping nearby; this is moving quickly.

What the desktop app actually gives you

Spaces, tabs, and panes that follow the work

A space holds work on one machine, usually a repository. A tab holds a task. A tab can contain multiple panes, with terminals or mod panels beside each other.

That sounds familiar because the useful part is familiar. Split right or down, resize, zoom a pane, rename things, and move between tasks. You can also drag panes to rearrange them: drop on another pane to swap, or near an edge to put them beside each other. Spaces can be reordered in the sidebar.

Unnamed spaces follow their terminal’s folder; named ones keep the label you chose. New tabs start in the focused terminal’s folder. These are small decisions, but they remove the repetitive setup that makes a workspace manager feel like another thing to maintain.

The + menu starts a terminal or an installed agent, and custom commands can join it through programs.json. You are not restricted to a particular provider’s coding agent.

An agents list that answers the useful question

The sidebar brings agents together, including workers started by other agents. It can group them by space or prioritize the ones that need attention. You can pin agents you are watching and fold sections you don’t need.

The states are straightforward:

Working: still busy.
Blocked: waiting for you.
Done: finished while you were looking elsewhere.
Idle: not working, including a finished agent you have already looked at.

Tabs and spaces surface agent state too. Sounds and clickable in-app toasts can tell you when an agent needs you or finishes while you are elsewhere, and the sounds are configurable.

This is the part that makes my working day better. I don’t need to keep opening every terminal to ask whether anything happened. I can leave working agents alone and go where my input is actually useful.

There is an important change from the original TUI: herdr-core does not scrape screens to guess status. Programs report it through the open OSC 7501 protocol. Any terminal program can run; status reporting requires support for that protocol. An older agent that doesn’t report state still works, but it doesn’t magically become observable. Running it inside a nested tmux session can also prevent the report from reaching Herdr.

That boundary is cleaner than pretending every quiet terminal means the same thing.

Terminals that outlive the window

The window arranges the terminals. The core runs them.

Quit the desktop app, update it, or lose the window to a crash, and the terminals keep running in herdr-core. Open the app again and return to them. Updating the presentation layer does not need to interrupt the work.

But let’s keep the guarantees separate:

Closing the window leaves the terminals running.
Closing a pane or tab ends its terminals.
A reboot or core crash stops the programs. Kept panes come back with fresh shells in their last directories, not magically resumed agents.

I care about this distinction more than I care about the word “persistent” on a landing page. Surviving a closed window and surviving a machine reboot are different promises.

Remote machines without another mental inventory

Add a machine over SSH from Settings or the sidebar, choosing a host from your SSH config or entering the connection yourself. Its spaces appear under that machine, and its terminals run there.

Local and remote agents can then sit in the same working view. The remote jobs keep running when the local app closes or the laptop sleeps, provided the remote machine and core remain up.

Each machine keeps its own spaces, tabs, and splits. Connected screens share that structure and the live terminals while keeping their own focus and zoom. You are looking into the work, not relocating it to whichever computer happens to have the window open.

For people who spread work across a workstation, a server, and a few experimental environments, that is a useful reduction in bookkeeping.

Files, changes, and Git worktrees

The default layout includes Files and Changes panels.

Files gives you a tree and read-only previews, with syntax highlighting for code. Changes puts changed files and diffs beside the terminal, with a commit message field and a commit action. That matters because “the agent finished” is the start of review, not the end of the task.

One detail worth knowing before clicking: in this version, the Changes panel’s commit action runs git add -A followed by git commit. It is not a selective staging interface. If you need a carefully scoped commit, use your normal Git workflow rather than assuming that button only stages the file you are viewing.

Worktrees are first-class in the UI too. You can create, open, and remove them; their spaces nest under the repository, and the sidebar shows branch information, ahead/behind status, and uncommitted changes.

Separate worktrees do not solve conflicting ideas or bad changes. They do make it much easier to keep parallel tasks from writing into the same checkout.

Sub-agents you can actually inspect

Workers started through hc appear under their parent agent. A worker without its own pane can open in peek, over the current tab, and you can keep it as a tab when it deserves a permanent place.

A live terminal address in output is actionable too: Ctrl-click it, or Cmd-click on macOS, to peek at that terminal. An agent mentioning another worker no longer has to send me on a hunt for the corresponding pane.

Underneath, herdr-core provides commands to start programs, read their output, send input, and wait for them. The desktop makes that activity visible without requiring every temporary helper to become another permanently open pane.

The everyday terminal details

There is more here than a sidebar and a status protocol:

Clipboard text, copied files, and image paste, including transferring clipboard images to a remote terminal and pasting their remote path.
Kitty graphics support, including the placeholder images used by programs such as yazi.
Scrollback, word and line selection, and selection that scrolls when you drag past the terminal edge.
Mouse-aware terminal programs, with Shift-selection when you want to select text instead.
Clickable links and terminal-address peeks.
A command palette that lists actions and their shortcuts.
Rebindable keys, including explicitly passing a key through to the terminal program.

The last one is particularly useful when the app and an agent want the same shortcut. By default, Ctrl+Shift+B toggles the sidebar. If your terminal program uses that combination, you can resolve the collision in keys.json rather than pretending your muscle memory is wrong.

None of these features makes a dramatic launch headline. All of them matter when the app stays open all day.

The interface is files, not a fixed opinion

This is the other part I find genuinely exciting.

Herdr keeps its interface in ~/.config/herdr-app: settings, keybindings, layouts, themes, program definitions, and mods. There is an AGENTS.md there explaining how to work with them.

You can change fonts, colors, light and dark appearance, zoom, alert sounds, pane styling, and backgrounds. But customization goes beyond choosing a palette:

Layouts describe the window’s structure.
Mods provide panels, menus, dialogs, and other UI pieces.
Keys decide how you drive it.

The built-in layouts include Herdr, a more terminal-focused layout, and Herdr 98. Yes, the Windows 98 one. That is fun. The more important point is that the default sidebar and tab bar are not privileged components you can never touch; they are built from the same parts available to your own mods.

Want a timer on each agent’s tab? A board with working, blocked, and done columns? A different sidebar? Those are things you or an agent can build, not promises that require waiting for an upstream preference checkbox. The official guide gives examples, and there are shared layouts and mods to start from. A phone notification through ntfy, for example, is a mod you add, not a built-in notification service.

Personal edits reload while the app runs. An invalid edit keeps the last good version and reports the error. Duplicate shipped layouts and mods before changing their structure or code; the originals are maintained by Herdr and replaced on startup.

There is a useful control surface around this too:

herdr-app --skill      # the agent guide for the window
herdr-app commands    # available actions and arguments
herdr-app status      # focus, layout, overlays, and errors
herdr-app shot        # a PNG of the rendered app window
hc --skill            # the runtime guide

An agent can read how the interface works, change it, validate a mod, and capture the result to inspect it. I still want to review what it changed. But that is a much more useful arrangement than an agent blindly editing settings for a UI it cannot see.

A few things I would not gloss over

I like this app. That doesn’t exempt it from the boring questions.

It is still early software. The recent changelog includes fixes for freezes, background CPU use, input methods, clipboard behavior, and rendering. That is active progress, and also a reason to try your actual workload rather than assume every terminal edge case is solved.

Mods are trusted code, not sandboxed decorations. They can execute programs, access files, make network requests, and run programs on connected machines. Community listings are not a security review. Read what you install; an agent reading it for you does not turn it into audited software.

Desktop telemetry is enabled by default. My earlier TUI post mentioned that project’s no-telemetry statement. Do not carry that assumption into this app. The desktop documents daily usage reports, excluding terminal text, prompts, and file contents. You can inspect the report and disable collection in Settings → Privacy. The security documentation explains the details.

The licensing is different too. The desktop app and herdr-core are Apache-2.0 projects; don’t apply my earlier discussion of the TUI’s AGPL license to them.

Installed releases download updates in the background, expose release notes and app/core update controls, and switch app versions on restart while the core keeps the terminals alive. Convenient, but still software updating itself on your machine. Know the behavior before deploying it into a controlled environment.

Worth a try

The downloads page has builds for Linux x86_64 and ARM64, Apple Silicon macOS, and x86_64 Windows. Linux needs a desktop session and a working Vulkan driver. Intel Mac users need to build from source rather than use the published Mac binary.

My recommendation is simple: give it one real project. Run the agents you already use, keep a test runner beside them, open the changes panel, and add a remote machine if that is part of your normal day. Don’t manufacture a complicated multi-agent demonstration just to justify installing it.

Then pay attention to how often you have to go looking for the work.

That is where Herdr Desktop won me over. The terminal capabilities I care about are still there. The surrounding work is easier to see, easier to reach, and easier to arrange around how I actually operate.

It doesn’t make agents infallible. It doesn’t review their changes for me. It makes working with them considerably better.

It’s finally here. And yes, it’s worth a try.