Hermes Agent CN Desktop: a Tauri shell for the Hermes Agent runtime on Windows and macOS

The shell problem Hermes Agent CN Desktop actually solves

The project's own positioning section states that Hermes Agent already provides a local Dashboard, and that this repository focuses on the desktop experience outside that Dashboard: native windows, local process management, file dialogs, managed runtime installation, runtime diagnostics, a safer REST proxy layer in production mode, and a WebSocket relay when one is needed. That sentence is the whole scope. If you are already happy running `hermes dashboard` in a browser tab, this repository adds little for you.

The audience is narrower than the topic list suggests. The README says the desktop client is built by the Hermes Agent Chinese community and is adapted for Windows and macOS users, with a bundled Hermes-CN-Core runtime so that after installation you configure an API key or a local model endpoint and start working. The download table lists three artifacts: a macOS Apple Silicon DMG, a macOS Intel DMG, and a Windows x64 installer. There is no Linux artifact in that table, and the development prerequisites describe macOS and Windows toolchains.

So the problem is packaging and supervision, not agent capability. The agent runtime and the Dashboard source live in a separate repository, Hermes-CN-Core. This repository is, in its own words, the desktop shell.

Inside the Tauri shell: Rust commands, a bundled runtime, and a WS relay

The architecture is visible in Cargo.toml. The Rust side is a Tauri v2 application with `tray-icon` and `devtools` features enabled, plus plugins for dialog and notification. HTTP work goes through `reqwest` with `rustls-tls`, `cookies`, `json`, `multipart` and `stream` features, which matches the claim that production mode proxies REST and uploads through Rust commands and handles authentication in one place. A `notify` v6 dependency backs the right-rail preview's file refresh, and the comment in the manifest says raw change events are emitted to the renderer, which debounces before re-reading.

WebSocket traffic has its own path. The manifest comment describes a relay to the runtime's native `/api/ws`, implemented in `commands/ws_proxy.rs`, and notes that the relay also carries remote-mode connections, which may use `wss:`. The README frames this as a workaround: in packaged builds the app can route through a Rust WS relay to get around WebView limitations. That is a real design constraint, not a feature. It means the browser-side WebSocket client is not trusted to reach the gateway directly in every configuration.

Runtime management is the other half. The README states the desktop client can install, update, verify signatures, health-check and roll back the local Hermes Agent core. The Cargo.toml dependency list includes `ed25519-dalek` with `pkcs8` and `pem`, `sha2` and `zip`, which is consistent with signed archive verification. The README also says current Windows and macOS installers pre-bundle the `Hermes-CN-Core` runtime, and that the managed runtime download and update flow is used only as an upgrade or fallback path. That ordering matters: first run should not depend on a network fetch.

Installing Hermes Agent CN Desktop and running it for the first time

Installers come from the desktop site at desktop.hermesagent.org.cn or from the GitHub Releases page. The README names the current artifacts explicitly: `Hermes.Agent.CN.Desktop_0.8.0-rc8_aarch64.dmg` for macOS Apple Silicon, `Hermes.Agent.CN.Desktop_0.8.0-rc8_x64.dmg` for macOS Intel, and `Hermes.Agent.CN.Desktop_0.8.0-rc8_x64-setup.exe` for Windows x64. There is no separate runtime download step for a normal install, because the runtime is bundled.

If you are building from source instead, the prerequisites are Rust stable, Node.js 20 or newer, pnpm 9 or newer, and either Hermes-CN-Core or a locally installed Hermes CLI for local Dashboard development. On macOS the README also asks for Xcode Command Line Tools:

xcode-select --install

Dependencies install with pnpm. The `preinstall` script in package.json runs `node scripts/only-pnpm.mjs`, so npm and yarn are rejected before anything else happens:

pnpm install

The development flow expects the Hermes Dashboard running in a second terminal. The README gives the host, port and flag exactly as below, and the port is 9120:

hermes dashboard --host 127.0.0.1 --port 9120 --no-open

Then start the desktop side. The README shows both a manual split and a managed variant that starts Vite automatically:

pnpm web:dev
cargo run

pnpm tauri:dev

For a production package, `pnpm tauri:build` runs the licence sync, the version sync and then `tauri build`. On first launch of an installed build, the README says the app initialises the local core from the bundled runtime, after which you configure an API key or point it at a local endpoint such as Ollama, vLLM, LM Studio or llama.cpp.

YOLO mode, devtools in release builds, and the licence you are accepting

Two decisions in this repository deserve a direct read rather than a feature-list skim.

The first is YOLO mode. The README describes a switch at the bottom of Settings, General, in a separate high-risk operations area. Turning it on requires a second confirmation, it auto-approves dangerous commands, it maps to the backend variable `HERMES_YOLO_MODE`, and toggling it restarts the kernel so the change takes effect. A restart-on-toggle is a sensible way to avoid a half-applied state, but it also means the switch is not something you flip casually mid-task. If your workflow involves an agent issuing shell commands, this setting is the single highest-consequence control in the app.

The second is devtools. Cargo.toml enables the `devtools` feature with a comment explaining that it keeps the WebView inspector available in release builds too, so the desktop ships in developer mode by default and the inspector is toggled by a keyboard shortcut. The same comment notes that on macOS this uses a private API, which the authors accept because the DMG is not distributed through the App Store. That is a coherent trade-off for a developer-facing tool, and a poor fit if your organisation requires store distribution or forbids private API use on macOS.

The licence is PolyForm Noncommercial 1.0.0, per the README badge and the LICENSE file. GitHub reports the licence as NOASSERTION because it is not an OSI-approved identifier. The practical point is that this is a source-available noncommercial licence, not MIT or Apache-2.0. Check how you intend to deploy it before you build anything on top of it. Nothing here is legal advice; read LICENSE.

Where Hermes Agent CN Desktop is the wrong tool

Linux is the clearest boundary. The README says the client natively supports Windows and macOS, the download table has no Linux artifact, and the prerequisites describe macOS and Windows toolchains. Nothing in the README suggests a Linux build exists. If Linux is your target, this project does not cover it today.

Version stability is the second boundary. The README warns that the project is still iterating quickly and that the API, packaging pipeline, runtime distribution strategy and interface details may keep changing. The release list reinforces this: the three most recent releases are all tagged `v0.8.1-prototype.592.7.1.x` with the note STAGING ONLY, and one of them carries a `badsig` suffix. A staging-only tag with a bad-signature variant is not a channel you want behind an unattended deployment. Treat this as software you upgrade deliberately.

Third, this is a client. If your problem is agent behaviour rather than desktop packaging, the work happens in Hermes-CN-Core, and the README is explicit that the runtime and Dashboard source live there. Installing this shell will not change what the agent can do.

Finally, the bundled-runtime design means your installed runtime version is tied to the installer you downloaded. The README says the managed download path exists as an upgrade or fallback, but it does not document what happens when that path is unreachable, nor does it document the rollback procedure beyond stating that rollback is supported. If you need a documented recovery runbook for a locked-down network, the README is silent on it.

Hermes Agent CN Desktop versus running the Hermes Dashboard directly

The honest alternative is the thing this project positions itself against: the local Hermes Dashboard that Hermes Agent already provides, run in a browser. The README states that Hermes Agent already offers a local Dashboard and that this repository deliberately covers everything outside it.

The difference is where the process boundary sits. With the Dashboard alone, you start a server yourself (the README's own example is `hermes dashboard --host 127.0.0.1 --port 9120 --no-open`) and open a browser. You own the runtime install, the version, the update, and the question of whether the browser can reach the gateway endpoint. With the desktop client, Tauri supervises the runtime process, the runtime ships inside the installer, updates go through a signed path with health checks, and REST and uploads are proxied through Rust commands in production mode instead of being issued from the WebView. The WS relay exists for the same reason: to route around WebView limits in packaged builds.

That is a genuine capability difference, not a cosmetic one, and it is the reason to prefer the desktop build. The cost is that you inherit a faster-moving release channel and a noncommercial licence. If you are on Linux, or you want to pin a runtime version and manage it with your own tooling, the Dashboard route is the one that stays under your control.

Maintenance, upgrade cost, and what the repository tells you

The repository is not archived and the last push was on 2026-09-06. That is recent enough that the project is being worked on, but the release channel is the part that affects your upgrade cost. All three recent releases are marked STAGING ONLY and use prototype version strings. The README's own warning that packaging flow and runtime distribution strategy may change means you should expect installer names, artifact layout and runtime handling to move between versions.

On the build side, package.json wires version and licence consistency into the normal workflow: `version:sync` and `license:sync` run before `tauri:build`, and `typecheck` runs `license:check`, `version:check` and `grid:check` before the workspace typecheck. If you fork this, those scripts are the ones that will fail first when you bump a version in one place and not another. The `preinstall` guard against non-pnpm package managers is another small thing that will bite a contributor who reaches for npm out of habit.

The licence question is the one to settle before you invest. PolyForm Noncommercial 1.0.0 restricts commercial use, GitHub reports the identifier as NOASSERTION, and the README links LICENSE directly. Whether your use counts as commercial is a question for your own counsel, not for this article.

Editorial conclusion

Adopt Hermes Agent CN Desktop if you run Windows or macOS, want a packaged runtime instead of assembling Hermes-CN-Core yourself, and are comfortable with a version string that still reads 0.8.0-rc8 and release tags marked STAGING ONLY. Do not adopt it if you need Linux, if you want a stable versioned API, or if the PolyForm Noncommercial licence conflicts with how you intend to use it. Before installing, confirm the runtime version bundled in your installer, check whether your target machine can reach the managed runtime download path, and decide whether YOLO mode will stay off.

Frequently asked questions

Official sources

1. Eynzof/Hermes-CN-Desktop on GitHub
2. Issues
3. Project website
4. README
5. Releases