Hermes Desktop OS1 Edition: a native macOS workspace for Hermes Agent on Orgo cloud computers

The gap OS1 fills: an agent that needs a machine, not just a chat box

Most desktop AI clients assume the model is the whole product. Hermes Agent assumes the opposite: it expects a host with a filesystem, a shell, and a place to keep state. That mismatch is what OS1 targets. The README describes it as "a native macOS interface for an AI agent that lives in a cloud computer," and the workflow it supports is concrete: provision a computer, hand it to the agent, then stay in one workspace with sessions, kanban, files, skills, cron jobs, and a terminal.

The audience is narrow and identifiable. You need a Mac, macOS 14 or newer, and either an Orgo account with an API key or a host you already reach with ssh from that Mac without interactive prompts. If you are comfortable in a terminal and your agent already runs on a box you control, OS1 adds a GUI layer you may not want. If you want the agent to have its own disposable Linux machine and you would rather not wire up SSH keys, provisioning, and an installer by hand, that is the case this app was built for.

How the Orgo transport actually routes: proxy first, direct VM on failure

The routing section of the README is the most informative part of the repository, because it explains a fallback that most GUI clients hide. For cloud connections, HTTP operations such as /bash and /exec try the platform proxy at https://www.orgo.ai/api/computers/{id}/... first. If that returns a 5xx that looks like a routing failure (the README names ECONNREFUSED, gateway timeout, and stale port), the transport falls back to the direct VM URL https://<fly_instance_id>.orgo.dev/... using the VNC password as the bearer token.

Two consequences follow. First, long-running operations skip the proxy entirely, because the README states its request timeout is 30 seconds and the agent installer would always trip it. Second, the terminal does not use the proxy at all: it opens a websocket directly to wss://<fly_instance_id>.orgo.dev/terminal?token=<vncPassword>. That is a deliberate design choice with a security shape worth noticing. The app talks to the platform HTTP API and the per-VM websocket terminal with no SSH, no gateway, and no helper service on the VM, which removes a lot of setup, and also means the VNC password doubles as a bearer credential for direct VM access. The README does not discuss rotating that password.

Installing OS1 and connecting your first Orgo computer

The README gives a download-and-drag install rather than a package manager. You get the latest OS1.app.zip from the GitHub Releases page, unzip it, drag OS1.app into /Applications, and launch. The build is universal and ad-hoc signed, so on first launch macOS may say it cannot verify the developer; the README says to right-click the app, choose Open, and confirm.

If you prefer to build it yourself, the repository ships a packaging script. The bundle lands at dist/OS1.app.

./scripts/build-macos-app.sh

Tests run through Swift Package Manager.

swift test

For a live cloud computer, the README documents integration tests that are skipped by default and only run when you opt in with environment variables. Note the filter name, since it is the only test target named in the README.

ORGO_LIVE_TESTS=1 \
ORGO_API_KEY="sk_live_..." \
ORGO_DEFAULT_COMPUTER_ID="<uuid>" \
swift test --filter OrgoTransportLiveTests

In the app, setup is a wizard. Open the Connections tab, click Add Host, switch the transport picker to Orgo VM, paste your API key, and click Verify & Save. The README states the key persists in the macOS Keychain and later connections reuse it. Then pick a workspace from the dropdown, pick a computer or click Create new computer, and save. The inline defaults are Linux, 8 GB RAM, 4 CPU, 50 GB disk. If the agent is not on the VM yet, the Overview screen shows an install banner, and one click runs the official Hermes Agent installer. The README puts that at roughly 60 to 90 seconds and says Sessions, Kanban, Files, Skills, and Cron populate afterwards. You can use the rest of the app while it runs.

Voice mode, the local MCP bridge, and why the toolset defaults are conservative

OS1 ships a WebRTC voice mode built on OpenAI Realtime calls with gpt-realtime-2. The Swift side starts a loopback session endpoint when the boot animation finishes; the browser surface in the app posts raw SDP to POST /session, and the Swift endpoint keeps OPENAI_API_KEY server-side, forwarding the SDP to https://api.openai.com/v1/realtime/calls using multipart FormData fields named sdp and session. The bottom-left Voice row toggles the connection, and there is no separate voice control panel.

The more interesting part is the Orgo MCP bridge. OS1 starts the MCP server locally, reads tools with tools/list, registers them with session.update, and forwards model tool calls back to tools/call. Orgo credentials stay in the Swift app and are never sent to the browser or model, which is the right boundary given that a voice model is driving the calls. By default the bridge runs npx -y @orgo-ai/mcp, exposes core,screen,files, disables file upload, and passes the active connection's computer ID as ORGO_DEFAULT_COMPUTER_ID. The overrides are all environment variables.

OS1_ORGO_MCP_JS_PATH="/absolute/path/to/dist/index.js"
OS1_ORGO_MCP_PACKAGE="@orgo-ai/mcp"
OS1_REALTIME_ORGO_TOOLSETS="core,screen,files"
OS1_REALTIME_ORGO_DISABLED_TOOLS="orgo_upload_file"
OS1_REALTIME_ORGO_READ_ONLY="true"

shell and admin are opt-in through OS1_REALTIME_ORGO_TOOLSETS, and the README's own warning is blunt: only enable them for agents and computers you are comfortable letting a voice model operate. That sentence is the honest part of the design. A voice model with a shell toolset on a cloud computer is a genuinely different risk category from a voice model that can read files. Running from source with an environment fallback looks like this.

OPENAI_API_KEY="sk-..." swift run OS1

The macOS-only boundary and the SSH path that still needs python3

The clearest limitation is the platform. Requirements list macOS 14 or newer, universal build, and nothing else. There is no Linux or Windows build in the README, so anyone asking whether the Hermes Agent desktop app runs on Linux or installs on Windows 11 has their answer: not through this project. That is a real constraint, not a packaging detail, because the app is Swift and the voice bridge is a Swift endpoint.

The SSH path is the fallback for hosts you already reach, and it inherits the upstream fork's flow. It is not free of prerequisites. The README states the host needs python3 on the non-interactive SSH PATH and Hermes already installed. So if your ssh access prompts for a password or a key passphrase, the app's flow will not work as described; the README specifies ssh "without interactive prompts." Cloud computers avoid that requirement because the app handles provisioning, agent installation, and the websocket terminal itself.

A second limitation is distribution. The build is ad-hoc signed, which the README addresses by explaining that the packaging script signs with an explicit designated requirement for com.elementsoftware.os1 so privacy grants such as microphone access survive rebuilds. For a stronger identity you set OS1_CODESIGN_IDENTITY or HERMES_CODESIGN_IDENTITY, or OS1_AUTO_CODESIGN=1 to use the first available Apple Development identity. If you are distributing this to other people rather than running it yourself, ad-hoc signing is a step you will want to replace.

How OS1 differs from running Hermes Desktop upstream by itself

The most direct alternative is the upstream Hermes Desktop, which OS1 was forked from. The difference is the transport layer. Upstream's flow, as the README describes it, is SSH: you need a host you already reach over ssh without interactive prompts, python3 on the non-interactive SSH PATH, and Hermes already installed there. OS1 keeps that path ("Same flow as the upstream Hermes Desktop fork OS1 was built on") and adds Orgo cloud computers on top, with VM provisioning, one-click agent installation, and a per-VM websocket terminal.

The practical split is who does the machine work. With upstream, you own provisioning and installation, and you get a client for machines you already have. With OS1, the app owns provisioning and installation for Orgo computers, and you get a client that can create its own backend. The cost of that shift is dependency: the Orgo path requires an Orgo account and API key, and the routing section shows the app talking directly to Orgo's HTTP API and per-VM websocket endpoints. If Orgo is not your infrastructure, upstream plus your own SSH hosts is the simpler choice, and OS1's cloud features simply do not apply.

Licence, maintenance and what upgrades cost you

The repository is MIT licensed. That is permissive and places few obligations on how you use or redistribute the code, though the repository also carries a THIRD_PARTY_NOTICES.md file, and the app depends on external services (Orgo, OpenAI) whose own terms are separate from the MIT grant. Nothing here is legal advice; if you plan to redistribute a build, read LICENSE and THIRD_PARTY_NOTICES.md together.

On maintenance, the facts are limited. The repository is not archived, and the last push was on 2026-05-09. The repository has no published GitHub releases, yet the README's instruction to download OS1.app.zip from the GitHub Releases page is the only distribution channel described.

Upgrade cost is mostly environmental. Because the app calls the Orgo HTTP API and the per-VM websocket terminal directly, changes on the Orgo side can affect it without any change to the repository; the proxy-to-direct-VM fallback in the routing section exists precisely because routing failures happen. The voice bridge adds a second moving part, since it runs npx -y @orgo-ai/mcp by default and pins the model as gpt-realtime-2. Rebuilding from source is cheap (./scripts/build-macos-app.sh), but the packaging script's ad-hoc signing means microphone permission grants can be fragile across rebuilds unless you set OS1_CODESIGN_IDENTITY or OS1_AUTO_CODESIGN=1.

Editorial conclusion

Adopt OS1 if you work on a Mac running macOS 14 or newer and want the Hermes Agent to live on an Orgo cloud computer that the app provisions and installs for you, or if you already reach a host over non-interactive ssh and want the same workspace around it. Do not adopt it if you need Linux or Windows on the desktop, since the README lists only macOS, or if you are unwilling to paste an Orgo API key and let the app talk directly to the platform HTTP API and the per-VM websocket terminal. Verify first that your Orgo workspace can create a computer with the defaults the README gives (Linux, 8 GB RAM, 4 CPU, 50 GB disk), that macOS will open an ad-hoc signed build after you right-click and choose Open, and that the Hermes Agent installer completes on that VM, because everything else in the app depends on that one step succeeding.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nickvasilescu/hermes-desktop-os1 on GitHub
4. README