Hermes Desktop: a native macOS front end that talks to Hermes over plain SSH
The safest, simplest way to manage Hermes from your Mac. Pure SSH. No gateways, no exposed ports, no browser layer.
At a glance
- What is it?
- Hermes Desktop is a Swift and SwiftUI Mac app that drives an existing Hermes Agent install either locally or over SSH, with no gateway, no exposed ports and no browser layer. The interesting part is what it refuses to add, and the cost of that refusal is a distribution model you have to work around on first launch.
- Who is it for?
- Adopt Hermes Desktop if you already run Hermes on a Mac, a Raspberry Pi or a VPS and you want sessions, Kanban, cron and skills in one window without standing up a gateway or browser layer. Skip it if you need a notarized, drag-and-drop Mac app with no first-launch workaround, or if your Hermes host lacks a Hermes Agent build with upstream Kanban support and you expect the Kanban view to populate.
- Can I use it commercially?
- Yes. MIT 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 89 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not Hermes, it is the layer people keep adding on top of it
Hermes Agent runs on a host and keeps its state there: sessions, Kanban, cron jobs, skills, workspace files, usage. The README is explicit that Hermes Desktop does not create a second version of that state. There is no local mirror, no sync layer, no gateway API and no daemon installed on the host. The app reads the real session store, the upstream Hermes Kanban home, and the real scheduler state, and it edits files and skills in place with conflict checks before save. That is the whole design thesis, and it is stated as a deliberate restraint rather than a missing feature. The audience is correspondingly narrow: people who already run Hermes and want a Mac surface for it. If you do not already have a Hermes install, this app has nothing to show you, because every view is a view onto a host that must exist first. The README frames the intended feeling as legibility: you always know which host you are on, which Hermes profile is active, and which path the app is using. That is a claim about interface honesty, and it is the thing to judge the app against.
Service commands over SSH, not an API
The mechanism is the least glamorous option available. According to the README, the app runs the same service commands either locally or over SSH. There is no protocol of its own, no agent process to keep alive, and no port to open. Direct-local mode is for a Hermes install on the same Mac. SSH mode targets a Raspberry Pi, another Mac, a VPS or a remote server, and the README reduces the readiness test to one line you can run yourself: ssh your-host, with no password prompt and no host key confirmation. If that succeeds, the app is usually ready too. For SSH connections the stated prerequisites are SSH access, an accepted host key, non-interactive authentication and a working network route. The payoff of this architecture shows up in failure. The README argues that when a dashboard, gateway or agent configuration breaks, the direct machine path still works: inspect Hermes state, edit the relevant files, open a terminal, repair the system where the state lives. That is a real property, not marketing. It also means the app inherits every constraint of the shell it is standing on, which the next sections get into.
What the eight views actually cover
The README lists eight previewed views: sessions, terminal, Kanban, files, skills, cron jobs, usage, and settings. Sessions come from the real session store. Kanban comes from the upstream Hermes Kanban home. Cron jobs come from the real scheduler state. Files and skills are edited in place. The app supports multiple Hermes profiles for what the README calls a multi-agent workflow, and it saves reusable workflow presets locally on your Mac, then launches them against the selected connection and profile in a fresh Terminal tab. There is also an embedded terminal, local or over SSH, for cases where the shell is the right tool. Two of these deserve scrutiny. The Kanban view depends on the host running a Hermes Agent build with upstream Kanban support, and newer Kanban features appear only when the host exposes them. So the view is a window, not a compatibility shim. The workflow presets are the one piece of state that lives on the Mac rather than the host, which is a defensible split because they are launch instructions, not Hermes data.
Getting it running, and the Gatekeeper detour
Installation is a download, not a package manager. You take HermesDesktop.app.zip from the latest GitHub Release, double click to extract, quit any older running copy, drag HermesDesktop.app into Applications, and replace the old copy if macOS asks. First launch is a right click on the app, then Open, then confirm Open. The README states this remains the normal first-launch path on supported macOS versions. The reason is stated plainly: Hermes Desktop is currently ad-hoc signed and not notarized by Apple, so macOS may warn that it cannot verify the app for malware. The README notes this is expected for the distribution model and does not mean macOS found malware. There is a second, narrower case. 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 scopes the extra steps to that exact version and build and that exact alert. First verify the download: run shasum -a 256 ~/Downloads/HermesDesktop.app.zip and compare it with HermesDesktop.app.zip.sha256 attached to the same release. Do not continue if the values differ. After extracting the verified zip and moving the app to Applications, the README gives xattr -dr com.apple.quarantine "/Applications/HermesDesktop.app" followed by open "/Applications/HermesDesktop.app". It also states these commands do not disable Gatekeeper. That last sentence is the part worth reading twice, because a quarantine removal command pasted out of context is exactly the kind of thing people generalize.
Where the app stops being the right tool
Three constraints are visible in the material. First, the platform floor: macOS 14 or newer, and the build is universal for Apple Silicon and Intel. Second, the host needs python3 on the machine where Hermes runs, and Hermes data under that user's ~/.hermes, a named profile, or a configured custom Hermes home. Third, and the one most likely to bite, Sessions Chat, Terminal resume and workflow launch require the hermes CLI to be reachable through the app's prepared shell PATH. That is a shell environment dependency, and shell PATH problems are exactly the kind that produce a working-looking app with three dead features. The README does not describe how to inspect or override that PATH, so if the CLI is installed via a version manager or a shell function, treat this as unverified until you see it work. The broader wrong-tool case is administrative. The README draws a boundary between the two surfaces: browser for administration, Mac app for direct Hermes work. If your job is rotating API keys, reading logs or managing installation-level configuration, the official web dashboard is the surface the README points at. Hermes Desktop is for the daily loop, not for setup.
The dashboard is the alternative, and the difference is the backend
The README names the official Hermes web dashboard as complementary rather than competing, and the split is concrete. The dashboard is browser-based and covers configuration, API keys, logs, sessions, analytics, cron jobs, skills and web chat. Hermes Desktop covers sessions, workflows, Kanban, files, editable skills, usage, cron jobs and a real terminal, without adding another backend around Hermes. The difference is not the feature list, which overlaps substantially on sessions, cron and skills. It is where the code runs. The dashboard implies a server process and a browser; Hermes Desktop implies an SSH client and a local app bundle. That choice determines your failure modes. A dashboard can be reached from any machine with a browser, which is why it fits administration. Hermes Desktop is bound to a Mac, which is why it fits a workbench. If you need to hand a colleague access, or work from a locked-down corporate laptop, the dashboard is the only one of the two that will do it. The README's own framing makes this a routing decision rather than a preference.
Maintenance, upgrades and the licence
Upgrades are manual and follow the install path in reverse: download the new zip from the release page, quit the running app, drag the replacement into Applications and confirm the replace. There is no auto-update mechanism described in the material, and because the app is ad-hoc signed and not notarized, you should expect the first-launch right-click-Open step to recur after each upgrade rather than being a one-time cost. The release cadence visible in the supplied data is three releases between 2026-06-07 and 2026-06-18, which tells you the project is moving but tells you nothing about stability. The licence is MIT, which is permissive and places few obligations on you beyond retaining the copyright and permission notice in copies or substantial portions. That is a statement about the licence text, not legal advice; if you redistribute the app inside a company, have someone read the actual LICENSE file. One maintenance point the material does not resolve: because the app reads upstream Kanban state and depends on the host's Hermes build, a host-side upgrade can change what the app shows without any change to the app itself. Budget for that coupling.
Editorial conclusion
Adopt Hermes Desktop if you already run Hermes on a Mac, a Raspberry Pi or a VPS and you want sessions, Kanban, cron and skills in one window without standing up a gateway or browser layer. Skip it if you need a notarized, drag-and-drop Mac app with no first-launch workaround, or if your Hermes host lacks a Hermes Agent build with upstream Kanban support and you expect the Kanban view to populate. Verify three things before committing: that ssh your-host connects from this Mac without a password or host key prompt, that python3 and the hermes CLI resolve through the app's prepared shell PATH, and that the SHA-256 of HermesDesktop.app.zip matches the .sha256 file on the same release page.
Community notes