Herdr UI: native desktop control for a local Herdr daemon
Native client for Herdr on macOS, Linux, and Windows, built with Rust and GPUI. View terminal sessions, workspaces, Git worktrees, and agent activity through your local Herdr daemon.
At a glance
- What is it?
- Herdr UI is a Rust and GPUI desktop client for developers running Herdr who want terminal cells, worktrees, agent activity, reviews, and host controls in a native interface. It is not a standalone terminal emulator and cannot replace the required Herdr daemon.
- Who is it for?
- Adopt Herdr UI if you already operate Herdr and want its terminal sessions, Git worktrees, and agent sessions in one native desktop interface. Do not choose it as a standalone terminal or for users who cannot install and run the daemon.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Why Herdr UI belongs beside Herdr rather than in place of it
Herdr UI solves a presentation and control problem for developers who already use the Herdr daemon. That daemon owns terminal sessions and related state, while this client provides a desktop surface for macOS, Linux, and Windows users to inspect terminal cells, split panes, workspaces, Git worktrees, and AI agent activity. It is aimed at developers who want more than a raw terminal view, especially those coordinating multiple worktrees and agents.
The boundary matters. The README says to install the Herdr daemon first because Herdr UI is only its client. An absent target session may cause the app to start an already installed local `herdr server`, but the client does not install or upgrade that daemon. It also does not run another terminal emulator and does not wrap the TUI. The application paints cells supplied by the daemon, including split-pane content, so it is not positioned as an emulator-compatible replacement for that daemon.
This design makes the project a poor fit for someone seeking a conventional terminal emulator that starts from one self-contained installer. It is more relevant to a Herdr user who wants native navigation around sessions, repository worktrees, and agents. The project is also explicitly unaffiliated with Herdr and the Herdr website. Any compatibility expectation should therefore come from the client and daemon versions actually deployed by the operator, not from an implied vendor support arrangement.
How daemon terminal cells become a GPUI desktop interface
Based on the repository layout, the workspace separates the application, protocol, and client responsibilities across `crates/herdr-gpui`, `crates/herdr-protocol`, and `crates/herdr-client`. It is a Rust workspace using edition 2024 and a declared minimum Rust version of 1.96. GPUI supplies the native application layer, while the other crates isolate the protocol and daemon-facing client code from the interface.
The README describes the visible data path plainly: Herdr supplies terminal cells, and Herdr UI paints them natively. Split panes remain part of that content rather than being recreated through a local terminal process. Around those cells, the client presents a sidebar containing workspaces, linked worktrees, and agents with status dots for idle, working, or waiting states. Host cards and the status bar add CPU and memory information. For remote machines, the README says those measurements are read over SSH.
Several features extend beyond terminal rendering. Review tabs display unified diffs, changed files, numbered review notes, and controls for sending feedback to an agent. Browser tabs can display local pages, capture element screenshots, and send annotations to the originating agent. Worktree controls include creation, fan out, rename, checkpoints, closing, and deletion of a checkout. Teleport is intended to move a worktree to another host while retaining commits, uncommitted changes, tabs, splits, running programs, and agent sessions.
The repository's dependency list also shows that input and presentation are substantial concerns rather than a thin display layer. Dependencies include URL parsing, Markdown processing, image compression, cryptography, SSH-related functionality, platform graphics bindings, and terminal parsing components. The README also documents clickable terminal links, code navigation, inline images, file drops, editor groups, system notifications, sounds, and a macOS Dock badge.
Running Herdr UI from source for a first session
The documented installation path begins outside this repository: install the Herdr daemon first. The README links to Herdr for that installation, then identifies Herdr UI as a separate desktop client. The README excerpt does not include a release package installation command, so a command for downloading or installing packaged Herdr UI cannot be confirmed here.
For a source checkout, the repository's `justfile` provides a release run recipe. On Linux and Windows, it invokes the application crate with Cargo. On macOS, it creates a release bundle and opens `target/release/Herdr.app`, which the recipe explains is needed for macOS Local Network permission behavior involving Bonjour and SSH hosts on the LAN.
The source build command exposed by the `justfile` is:
cargo run --locked --release -p herdr-gpui --features qa-menuThis should build and launch the client, but it does not install Herdr itself. The reader should already have the daemon installed and should verify that a local `herdr server` can start when the target session is absent. If starting Herdr UI opens the native window with workspace and agent navigation, the basic client launch has succeeded.
A debug source run is also defined:
cargo run --locked -p herdr-gpuiThis omits both `--release` and the `qa-menu` feature. The repository's `rust-toolchain.toml` participates in toolchain selection, while `Cargo.lock` is used by both recipes. The workspace declares Rust 1.96 as its minimum version. A failure caused by an older local Rust toolchain should not be interpreted as a runtime or daemon compatibility failure.
Worktree, agent, and review workflows built around daemon state
Herdr UI's strongest distinction is its integration of terminal state with Git and agent-oriented desktop actions. The sidebar associates agents with a repository and worktree context, while each agent carries the daemon-provided status dot. That status can distinguish an idle agent, one working, and one waiting for the user. This makes Herdr UI more useful than a simple terminal window when several agent sessions are active across linked worktrees.
Worktree actions are exposed from the interface rather than documented as standalone CLI commands. Right-clicking a workspace or worktree opens actions for New worktree, Fan out, Rename, Teleport, Teleport back, Close, and Delete worktree checkout. The screenshots also show Checkpoints. The exact implementation and failure behavior of each action are not documented in the README excerpt, so operators should not treat the menu labels as evidence that every Git state can be moved or deleted without failure.
The review workflow has a more concrete sequence. From the tab strip's `+` menu, select Review Changes. The client opens a unified diff of uncommitted changes, includes a changed-files list, and allows a user to click a line and leave a numbered note. Send to agent returns those notes to the relevant agent. A side-by-side layout is available, and the sidebar can collapse to an icon rail.
Browser annotation follows a related feedback path. The README gives the command `herdr-gpui browser open` as the way an agent opens a page. In the resulting browser tab, the user selects elements or regions, writes notes, and sends them back to the agent. Listening ports such as `:4173` appear under the workspace. Herdr UI therefore acts as a bridge between a live local page and an agent session, but it remains dependent on the daemon's session and workspace model.
Desktop convenience with a mandatory daemon dependency
Herdr UI offers conveniences that a conventional terminal does not provide, including saved SSH hosts, remote host resource readings, worktree teleporting, inline images, clickable links, code navigation, notifications, and agent status. Its themes and appearance settings also extend beyond raw terminal rendering. Built-in and Ghostty themes are available with a live preview, while layout choices can be changed from View or Settings and applied immediately.
The first limitation is architectural. Without an installed Herdr daemon, this repository cannot supply the full product described by the UI. The application may start an already installed local `herdr server`, but it explicitly will not install or upgrade one. That rule avoids hiding daemon lifecycle operations inside a desktop client, but it creates a version and installation burden for users evaluating the application as one unit.
Another boundary concerns scope. The README describes client workflows, not the daemon's implementation guarantees. It does not define which platforms or daemon versions are supported together, how migrations are handled, or what recovery behavior applies if teleporting fails while programs are running. The repository's separate protocol and client crates may reduce UI coupling, but the README does not promise backward compatibility across arbitrary daemon releases.
Herdr UI is also the wrong tool when browser annotations, diff review, worktree management, and multiple agent sessions provide no value. A plain terminal remains the more direct choice for a single local shell. Likewise, users who need a client that can install, upgrade, and supervise Herdr itself should use the daemon's installation route rather than assuming the desktop app covers that lifecycle.
Release cadence, source upgrades, and Apache-2.0 obligations
The repository is not archived, and the last push was on 2026-10-16. Recent release entries include Herdr UI 20261014.1 on 2026-10-15, 20261013.1 on 2026-10-13, and 20261012.1 on 2026-10-12. That pattern shows recent release activity, although it does not establish long-term support or compatibility guarantees.
The workspace metadata states that releases carry a derived calendar version in the form `YYYYMMDD.COUNTER`, which CI embeds as `HERDR_RELEASE_VERSION`. The Cargo package version remains `0.1.0` and is described as metadata only. This separation is important for source operators: the version visible in the UI should not be inferred from the workspace package version.
The README links to `docs/updating.md` for app updates, but that document's instructions are not included in the README excerpt. It is therefore unsafe to state whether packaged upgrades are automatic, staged, or manually downloaded. Source builds also carry upgrade cost because the workspace pins Rust 1.96 as its minimum and the `justfile` uses `Cargo.lock`. Anyone building from source must account for platform dependencies and compile time rather than treating the GUI as a dependency-free executable.
The repository and workspace metadata identify the license as `Apache-2.0`. The top-level tree includes `LICENSE` and `NOTICE` files. This identifies the stated licensing model for the project, but it is not evidence that every external daemon, remote host, AI service, or user-generated file is covered by the same terms. Organizations should review those component boundaries separately rather than treating the client licence as a blanket grant for an entire Herdr deployment.
Choosing Herdr UI against a plain terminal or web interface
The closest alternative described by the repository is a plain terminal-based interaction with Herdr, without Herdr UI's native workspace layer. A terminal is simpler and avoids the GPUI client's additional build and desktop integration requirements. Herdr itself remains the underlying session system in both cases, so switching to the plain terminal route does not remove the need for the daemon if the desired workflows depend on Herdr state.
Herdr UI takes a different approach from browser-hosted administration panels because it is a native client connected to a daemon the user installed. Its screenshots and README emphasize local OS integration, direct access to saved SSH hosts, native settings, system notifications, sounds, file drops, and a macOS Dock badge. The trade-off is a larger application built from Rust and GPUI, with platform-specific packaging behavior and more moving parts than a text interface.
It is also different from a standalone terminal emulator. Herdr UI does not interpret the session as an independent local terminal stack or wrap the daemon's TUI. It renders the daemon's terminal cells and adds navigation and review functions around those cells. Consequently, adopting it changes the interface and workflow, not the ownership boundary of the session system.
For an evaluation, the first useful comparison should be operational rather than visual. Record whether Herdr must run continuously, which local and remote hosts must be reachable, whether worktree teleporting is part of normal work, and whether agents need structured change review. Herdr UI is most compelling when those conditions are present and least justified for a single-shell user who values the smallest setup.
Editorial conclusion
Adopt Herdr UI if you already operate Herdr and want its terminal sessions, Git worktrees, and agent sessions in one native desktop interface. Do not choose it as a standalone terminal or for users who cannot install and run the daemon. Before adoption, verify that your required Herdr installation, saved SSH hosts, browser review workflow, worktree operations, and platform-specific update path match the ways your team works. The most important boundary is that this repository builds a client, not the daemon.
Frequently asked questions
Does Herdr UI install the Herdr daemon?
No. The README says to install the Herdr daemon first because Herdr UI is only its client. It can start an already installed local `herdr server` when a target session is absent, but it never installs or upgrades the daemon.
Does Herdr UI run its own terminal emulator?
No. It paints terminal cells supplied by the Herdr daemon, including split panes, without running another terminal emulator or wrapping the daemon's TUI.
Can Herdr UI review and send agent changes?
Yes. Review Changes displays a unified diff and changed-file list, supports numbered notes attached to lines, and provides Send to agent. A side-by-side review layout is also documented.
Can Herdr UI move worktrees to another host?
Yes. The documented Teleport feature moves a worktree to a saved SSH host with its commits, uncommitted changes, tabs, splits, running programs, and agent sessions. The README does not define recovery behavior if that operation fails.
What Rust version is declared for Herdr UI?
The workspace metadata declares Rust 1.96 as its minimum version and uses edition 2024. The repository's run recipes build the `herdr-gpui` package from the workspace.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/penso-herdr-gpui)Was this useful?