Hermes Lived in the Terminal. Now It Has a Desktop Window.

Hermes Desktop puts a native window on Nous Research’s autonomous agent. The real feature isn’t the chat. It’s watching the agent work, and keeping your writing, code, clients, and credentials from bleeding into one another.

A desktop app for an autonomous agent is a strange object when you stop to think about it. Most apps are for tools you operate: you click, the thing responds, you click again. Hermes isn’t that. It’s an agent that plans, runs commands, and keeps working on a server whether or not anyone’s looking. So what is a window for, when the thing behind the glass doesn’t need you to watch it?

That question is the most interesting part of Hermes Desktop, the native app Nous Research just pushed into public preview for macOS, Windows, and Linux. It’s been showing up in NVIDIA’s orbit too: NVIDIA’s own RTX AI Garage blog featured Hermes Agent running locally on RTX PCs and the DGX Spark workstation, which tells you who Nous wants paying attention.

The short version: Hermes used to be a terminal daemon and a pile of messaging bots. Now it has a face. The longer version is better, and it starts with one design decision.

One agent, many faces

Hermes Desktop is not a separate program that talks to the agent. It’s the same agent, wearing a window.

It installs the standard runtime into the standard ~/.hermes layout and shares everything with the CLI and the gateway: the same config, the same API keys, the same sessions, skills, and memory. Nous calls it "another surface over one agent, not a fork," and the phrase earns its keep. Start a task in the desktop window, close the window, and the work keeps going as long as the backend you pointed it at is still up. Pick the same conversation back up later from Telegram, or from the terminal, and it's all there. Nothing gets copied between surfaces. There's one brain, and the window is a way to look at it. If you've used hermes in a terminal, everything you set up there is already here.

That reframes what you’re installing. It isn’t a control panel that owns the process. It’s a viewport into something already running.

The window’s real job is oversight

The chat area streams responses and live tool activity, so you watch the agent plan a step, fire a terminal command, and read the result as it happens. A right-hand rail renders web pages, files, and tool outputs off to the side while you keep talking. A file browser lets you follow along as it reads and edits the working directory. There’s drag-and-drop file attachment, voice in and out, and a model picker for switching models mid-session.

Here’s the part worth saying plainly. The point of a GUI here isn’t convenience. It’s oversight.

When an agent runs shell commands and rewrites files on its own, watching the tool calls stream in plain view is the difference between trust and a blind leap. The terminal showed you this too, in its way. The preview rail and the file browser make it legible to people who don’t read scrollback for a living.

Profiles are the feature that earns the install

This is the one most coverage skips, and it’s the most useful thing in the app.

A profile is an isolated Hermes environment: its own config, its own skills, its own sessions, kept separate from every other profile. The desktop surfaces them as a pane you switch between. That sounds dry until you map it onto how you work, at which point it becomes the reason to bother.

Run one profile for writing and research, with the skills and memory that job has taught the agent. Run a second for coding, pointed at a sandboxed backend and a different model. Run a third for client troubleshooting, with its own credentials and messaging channels. They don’t bleed into each other. The agent that knows your Medium drafts doesn’t also have your client’s DNS records in its working memory, which is exactly what you want.

Most agent tools give you one big undifferentiated context and let it rot. Profiles are the fix, and having them behind a switch instead of a config file is what makes them get used.

One caveat worth saying out loud: a profile separates state, not filesystem access. It keeps your client’s records out of your writing agent’s memory. It does not stop either agent from reaching across your disk. That job belongs to the backend, which is the next thing to get right.

Point it at a folder

Launch the app against a specific project directory and the file browser and chat both start there:

hermes desktop --cwd ~/projects/my-app

For coding work, local document folders, or a research directory, this is the difference between an agent that’s loose in your home directory and one that’s scoped to the thing you’re working on. Set HERMES_DESKTOP_CWD if you'd rather not pass the flag every time.

Settings without the YAML

The old way to configure Hermes was editing config files by hand. The app exposes providers, model selection, credentials, toolsets, MCP servers, gateway settings, and sessions through a real UI instead.

That’s what flips it from a power-user tool into something a normal person keeps. The agent plumbing was always interesting; the config files were always the wall people bounced off. Browsing and toggling MCP servers in a panel, with no JSON to hand-edit, is the kind of small thing that decides whether someone sticks around past the first hour. Provider flexibility rides along here too: Nous Portal, OpenRouter, OpenAI, or your own endpoint, including a local Ollama or LM Studio server if you want the model running on your own hardware.

Where it runs (read this before you click install)

The window runs on your machine. Where the agent executes its commands is a separate backend choice, and it matters more than anything else on the screen.

The desktop page highlights five backends; the broader Hermes config docs list six, with Daytona the extra one:

• Local: commands run straight on your machine, with the same filesystem access as your user account. No isolation.
• Docker: container hardening and namespace isolation. The sane default for unattended work.
• SSH: execution on a remote box you control.
• Modal / Daytona: serverless bursts or persistent cloud workspaces.
• Singularity: rootless, HPC-style images.

Local is fine for read-only poking and reckless for anything left running. An agent with raw shell access can do to your home directory whatever a careless rm can, except it decided to on its own.

The UI is not the sandbox. The backend is. Switch to Docker or a remote backend before you let a self-running agent work without you in the room.

A sane default that maps the profiles above onto backends:

• Writing and research: local is fine; it’s mostly reading and drafting.
• Coding: Docker, so generated commands run in a container instead of your home directory.
• Client work: its own keys, its own working directory, no shared memory.
• Anything unattended: Docker or a remote box, never raw local.

Set it once per profile and you stop thinking about it.

A confusing detail worth clearing up

There are two different apps called “Hermes Desktop” right now.

One is the official Nous Research app described above, the one demoed at GTC. The other is fathah/hermes-desktop, a community-built Electron companion that's moving fast and, on a few fronts, further along. It adds a persona editor for the agent's SOUL.md, a Kanban board, an Office surface, SSH-tunnel control of a remote backend, around a dozen providers, and sixteen messaging gateways. It uses the same official install script and the same ~/.hermes directory underneath.

If you want the safest path and official support, take the Nous app. If you want the broadest feature set and don’t mind rough edges, the companion is worth a look, with two caveats: its Windows installer isn’t code-signed, so SmartScreen will warn you, and it ships releases often enough that something you relied on last version may move. Knowing both exist saves you an afternoon of wondering why two “Hermes Desktop” repos describe different features.

The honest catches

It’s a public preview, so plan for rough edges. The “Linux desktop” still installs from the terminal, which is a funny thing to admit about a desktop app. Prebuilt installers get attached to releases by hand, so they aren’t always there for the latest build, and the install-with-Hermes path is the reliable one. The breadth of what Hermes does means a real learning curve; this is not a five-minute toy you understand on first launch.

Then there’s the deeper tension. Hermes exists to run without you watching. A polished window is a little at odds with the product’s own thesis. The app earns its place in setup, inspection, and building trust, then gets out of the way. The value still lives on the server, not in the chrome.

Who should try it now

If you already run CLI agents, install it today. You lose nothing from the terminal and you gain oversight, profiles, a file browser, and settings you don’t have to hand-edit. It sits on top of the workflow you already have.

If you’re not technical, this still isn’t download-and-forget. The window removes a lot of friction, but the ideas under it (providers, models, tools, profiles, the gateway, sandbox backends) still ask for care. You’ll learn them, just with fewer config files in the way.

If you work with client data, the first thing to test isn’t the model. It’s profile separation and the sandbox. Get those two right before the agent touches anything that isn’t yours.

How to try it without overthinking it

Install it in one pass. On Linux, macOS, or WSL2, add the desktop flag to the standard installer:

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash -s -- --include-desktop

Already have the CLI? Just run hermes desktop and it builds and launches against your existing setup. Prebuilt .dmg, .exe, and .AppImage files show up on the GitHub releases page when a build is published.

1. Run first-run setup. It walks you through picking a provider and model and gets you to a first message in seconds. Nous Portal has a free tier to start, and one sign-in covers web search, image generation, text-to-speech, and a browser.
2. Make a profile per job. Don’t pile everything into one context. Spin up a writing profile, a coding profile, a client profile. Switch between them from the pane.
3. Scope it to a folder and watch it work. Launch with hermes desktop --cwd <path>, give it one real task, and use the preview rail and file browser to follow every tool call. Inspect before you trust. Set the backend to Docker before you let it run anything unattended.
4. Then close the window. Wire the gateway to Telegram, set one read-only cron job (“summarize the staging logs at 7am, message me only if something broke”), and pick the conversation back up on whatever surface you’re near. That round trip, from window to phone to terminal and back to one shared memory, is the entire pitch.

The desktop app doesn’t change what Hermes is. It changes who can stand to use it. A terminal daemon with persistent memory and a cron schedule was always going to stay a power-user thing. A window you can watch it think in, with profiles to keep your jobs apart, is how that thing reaches everyone else.