Hermes Desktop: a native macOS SSH client for Hermes Agent

Who Hermes Desktop is for, and what it refuses to add

The problem Hermes Desktop addresses is not that Hermes Agent lacks a way to run. It is that the daily loop around a Hermes host, meaning sessions, Kanban, workspace files, usage, skills and cron jobs, is spread across a shell and whatever ad hoc tooling a user has built. Hermes Desktop puts those surfaces in one focused macOS window. The README describes the target reader as someone for whom Hermes is already part of how they work, so the app should feel immediately legible: same host, same files, same profiles, same source of truth.

The design constraint is stated as plainly as the goal. No browser wrapper, no gateway API, no daemon on the host, no local mirror, and no extra sync layer that drifts away from the machine that matters. Every one of those omissions removes a component that could fail or fall out of date. It also removes a component that could cache, batch or smooth over a slow link. That is the trade the project makes, and it is the reason the app can still be useful when a dashboard or gateway is broken: the direct machine path stays open, so you can inspect real Hermes state, edit the relevant files, open a terminal and repair the system where the state actually lives.

How the app reaches Hermes: same commands, two transports

Hermes Desktop runs the same service commands either locally or over SSH. That single sentence in the README explains most of the architecture. There is no separate protocol for the app; the host's own Hermes service commands are the interface, and the transport is either a local process or an SSH connection. Sessions come from the real session store, Kanban from the upstream Hermes Kanban home, cron jobs from the real scheduler state, and files and skills are edited in place with conflict checks before save.

Direct-local mode is for a Hermes installation on the Mac itself. SSH mode covers a Raspberry Pi, another Mac, a VPS or a remote server. Because the app is a thin surface over real state rather than a mirror, it can only show what the host exposes. The README is explicit about the Kanban case: the native Kanban workspace needs a Hermes Agent build with upstream Kanban support, and newer Kanban features appear automatically when the host exposes them. Nothing in the app can conjure a feature the host does not have.

Two capabilities sit on top of the connection. Reusable workflow presets are saved locally on your Mac and then launched against the selected connection and profile in a fresh Terminal tab, so the preset is a local convenience while the execution stays on the host. An embedded terminal handles the moments where the shell is still the right tool. The app also supports multiple Hermes profiles for a multi-agent workflow, and the README's framing is that you always know which host you are on, which profile is active and which path the app is using.

Installing Hermes Desktop on a Mac

Hermes Desktop is not distributed through the Mac App Store. You download HermesDesktop.app.zip from the latest GitHub Release, double click to extract HermesDesktop.app, quit any older running copy, and drag the app into Applications, replacing the old copy if macOS asks. The first launch path is a right click on the app, then Open, then confirm Open.

The app is ad-hoc signed and not notarized by Apple. The README says a first-launch warning that Apple cannot verify the app is expected for this distribution model and does not mean macOS found malware in it. If the usual unidentified-developer warning appears, click Done rather than Move to Bin, right click the app and choose Open, and if needed use System Settings > Privacy & Security and click Open Anyway.

On some Macs running macOS 26.5.1 (build 25F80), Gatekeeper may instead report that the app is damaged and may not offer Open Anyway. The README gives extra steps only for that version and build, starting with a checksum check against the file attached to the same release:

shasum -a 256 ~/Downloads/HermesDesktop.app.zip

Compare the output with HermesDesktop.app.zip.sha256. The README says not to continue if the values differ. After extracting the verified zip and moving the app to Applications, clear the quarantine attribute on this app only and open it:

xattr -dr com.apple.quarantine "/Applications/HermesDesktop.app"
open "/Applications/HermesDesktop.app"

Before any of this, check the prerequisites. You need a Mac running macOS 14 or newer, python3 on the machine where Hermes runs, and Hermes data under that user's ~/.hermes, a named profile, or a configured custom Hermes home. For SSH mode you also need SSH access, an accepted host key, non-interactive authentication and a working network route. The README reduces the SSH check to one command, run from your Mac:

ssh your-host

If that connects without asking for a password or host key confirmation, the README says the app is usually ready too. For Sessions Chat, terminal resume and workflow launch, the hermes CLI must be available through the app's prepared shell PATH. The app ships as a universal build for Apple Silicon and Intel Macs and includes English, Simplified Chinese and Russian localization resources.

Where Hermes Desktop is the wrong tool

The first limitation is platform. The README describes a native macOS companion, and the repository's topics and primary language point the same way. There is no Windows or Linux build described in the README, so anyone asking for a Hermes desktop app on Windows or Linux has no answer here. The project's own homepage and release assets are the place to confirm that rather than assume it.

The second limitation is scope by design. Hermes Desktop deliberately does not become an administration surface. The README splits the work: use the official web dashboard for configuration, API keys, logs, sessions, analytics, cron jobs, skills and web chat; use Hermes Desktop for direct work from a Mac. If your job is rotating API keys, reading logs or managing installation configuration, the app is the wrong window, and the README says so.

The third limitation is dependency on the host and the shell environment. The hermes CLI must be reachable through the app's prepared shell PATH for Sessions Chat, terminal resume and workflow launch, so a PATH that works in your interactive shell may not be the PATH the app prepares. SSH mode additionally assumes an accepted host key and non-interactive authentication; if your setup prompts for a password or a host key decision, the README's rule of thumb says the app is not ready. And the Kanban workspace depends on an upstream Kanban-capable Hermes Agent build, so an older host shows less than a newer one. None of these are bugs to file; they are the cost of refusing to add a sync layer.

Hermes Desktop and the official web dashboard

The real alternative named in the README is Hermes' own web dashboard, and the difference is architectural rather than cosmetic. The dashboard is a browser-based management surface for the installation: configuration, API keys, logs, sessions, analytics, cron jobs, skills and web chat. It sits in front of Hermes with a browser layer and, by implication, the backend that serves it. Hermes Desktop sits beside Hermes with no backend at all, running the host's service commands over a local process or SSH.

That changes what each tool is good at. The dashboard is the better place to administer an installation, especially anything involving credentials and logs. Hermes Desktop is the better place to work inside one, especially when the higher-level surfaces are unavailable. The README's own framing is complementary rather than competitive: browser for administration, Mac app for direct Hermes work. If you already run the dashboard and it covers your needs, adding Hermes Desktop buys you a native window and a terminal, not a replacement. If you want a Mac client that keeps working when the dashboard or gateway does not, that is the case the app was built for.

Licence, releases and what maintenance costs you

Hermes Desktop is MIT licensed, with the LICENSE file at the repository root. In practical terms that is a permissive licence, and the repository also carries a SECURITY.md, which is where you should look for how the project wants vulnerabilities reported. Nothing in the README suggests a commercial tier, a hosted component or a licence key, so there is no vendor relationship to maintain.

The cost of keeping it current is a manual download. Releases are tagged, with v1.2.0, v1.1.1 and v1.1.0 the most recent listed, and the install instructions are written around replacing an existing copy in Applications rather than an in-app updater. The repository's last push was on 2026-06-19, and the most recent release, v1.2.0, was published on 2026-06-18. That is the state of the code as published, and it is the number to check against your own tolerance for a project you depend on.

Upgrade friction is mostly macOS friction. Because the app is ad-hoc signed and not notarized, every fresh download can trigger the same first-launch warning, and the macOS 26.5.1 damaged-app path requires a checksum comparison against HermesDesktop.app.zip.sha256 plus the quarantine removal. Budget for that on each upgrade rather than treating it as a one-time setup annoyance. The repository layout, with Package.swift, Sources/, Tests/, Vendor/, packaging/ and scripts/, indicates a Swift package with its own build and packaging tooling, so building from source is a real option if you would rather not trust a downloaded binary; the README documents the release download path, not a source build.

Editorial conclusion

Adopt Hermes Desktop if you already run Hermes Agent on a Mac, a Raspberry Pi, a VPS or another server you reach over SSH, and you want sessions, Kanban, cron jobs, skills and a terminal in one native window without adding a gateway or a browser layer. Do not adopt it if you need a Windows or Linux client, or if you want browser-based administration of configuration, API keys and logs; the README points that work at the official Hermes web dashboard instead. Before installing, confirm three things: that the machine where Hermes runs has python3 and Hermes data under ~/.hermes or a named or custom Hermes home, that ssh your-host succeeds from your Mac without a password or host key prompt, and that the hermes CLI is reachable through the app's prepared shell PATH, because Sessions Chat, terminal resume and workflow launch depend on it. Then verify the release zip against HermesDesktop.app.zip.sha256 before you clear the quarantine attribute.

Frequently asked questions

Official sources

1. dodo-reach/hermes-desktop on GitHub
2. License: MIT
3. Project website
4. README
5. Releases