This page is linked from Roxy’s status page. It records why a local Desktop would break Bob’s isolation deal, and why the live Cloud/Nous Desktop is OK.
Status: accepted. James confirmed August 16 that Bob’s Hermes Desktop is configured properly and uses Nous / Hermes Cloud as the backend — not a local agent. Daily setup is OK as-is. Do not rip Desktop out. Do not block the iMac move for this.
What’s left: a small Desktop-chrome leak (window title under the app, optional repo scan, anything Bob opens in the app’s own terminal pane), and delete any leftover unused local install so nobody can flip the app back to local.
Bob went to Nous Hermes Cloud so Roxy would be insulated from his personal and work files. The Mini was meant to be a safe client — a screen and a keyboard — not the machine the agent lives on.
That deal still holds for Telegram. A prompt-injected Cloud Roxy can see Bob’s research library, Honcho memory, Gmail, and Dropbox Inbox. She cannot browse the Mini’s disk, drive the mouse, or run shell commands as Bob.
Hermes Desktop, used the ordinary way, breaks that boundary.
Official Hermes docs are unambiguous. Desktop is not a thin chat window in front of Cloud Roxy. It is the same agent as the CLI and the gateway — same config, keys, sessions, skills, and memory. By default the app starts a local backend on the Mac. Commands then run on that Mac with the same filesystem access as Bob’s user account.
A few measured limits matter more than the marketing:
rm -r, curl | sh, and similar). Ordinary file reads, most writes, and Computer Use do not get a prompt. The current default mode is smart, which can auto-approve commands it rates as low-risk.write_file / patch only. The terminal tool can still read or overwrite those same paths with a shell command. Official wording: it does not sandbox a hostile or compromised agent.read_file can open whatever Bob’s user can open.desktop_ui toolset. Those are not the same as a local agent. See the measured Cloud-only section below.So the risk James named is real for a local backend: a poisoned Substack, a malicious page, or a bad skill instruction can ask a Desktop-hosted agent to read or change files on the Mini. Approvals will not reliably stop that.
This was the residual question from the first pass: if Desktop is pointed at Hermes Cloud, do file/terminal/Computer Use still run on the Mini?
No — those agent tools stay on Cloud. Opening a Cloud agent dials that source. Chats, sessions, memory, and workspace tools live on the machine that owns the profile. Official docs for the API-server path say the same thing in one sentence: tool calls run where that backend is running. The opposite design — “remote brain, local hands” — is an open feature request, not current behavior.
What does still touch the Mini is the Desktop app itself:
| Surface | Where it runs | What it can see on the Mini |
|---|---|---|
read_file / terminal / Computer Use |
Cloud backend | Nothing on the Mini. Cloud’s own sandbox only. |
desktop_ui (enabled on Cloud sessions) |
Desktop window, via a callback to the app | App chrome: panes, preview, the in-app terminal tab if Bob opened one. read_window_below returns the OS window under Hermes — app name, title, bounds. Never pixels. Titles need Screen Recording already granted; the tool never prompts for it. |
| Home-directory repo scan | Desktop app | Git folder names under home, to a bounded depth. Turn off with desktop.repo_scan_enabled: false. |
| File browser / embedded terminal | Desktop app, only if Bob opens them | Whatever Bob browses or types there. Not agent disk access unless he uses those panes. |
| Drag-and-drop into chat | User action → Cloud session | Only the file Bob dropped. |
So Cloud-only Desktop is a thin client with a small chrome leak, not a second Roxy on disk. It is not zero: Cloud Roxy can learn which app is under the window, can preview a local path Bob (or the agent) names, and can read an in-app shell Bob opened. It cannot cat ~/Documents.
Installer caveat: current Desktop source has a first-run “Connect to existing Hermes” path. The public macOS DMG advertised on the website has been reported as an older bootstrap installer that still forces a full local runtime. Until that download is current, assume a fresh Mini install may grow a local brain unless someone picks Cloud and confirms no local hermes serve / venv landed.
| Option | What Bob gets | What it actually protects | Verdict |
|---|---|---|---|
| 1. Telegram only Remove Desktop. Uninstall any local Hermes runtime. |
Same Cloud Roxy he already uses. Fat files still go through Dropbox Inbox (Telegram’s 20 MB cap is already solved). | Restores the original deal. No local agent on the work machine. | Zero-residual alternative. Not required. |
| 2. Keep Desktop, “prompt for every local action” | Nicer UI now, and a future mobile app if one ships as a thin client. | Stock Hermes cannot do this. Approvals cover a dangerous-command subset, not every read, write, or click. Selling this as safety is theater. | Do not ship as stated. |
| 3. Desktop as a Cloud window only Cloud connection. No local runtime. Repo scan off. Do not grant Screen Recording. Do not open the embedded terminal. Computer Use stays off. |
Desktop UI. Brain and file/terminal tools stay on Cloud. | Restores the original deal for disk and shell. Residual: window titles, preview of a named path, anything Bob opens in the app’s own terminal pane. Official installer may still plant a local runtime — confirm it is absent. | Live now. Accepted. |
| 4. Dedicated Mini, not the work Mini | Desktop can stay on a throwaway box that never holds client files, tax docs, or mail. | Honest isolation — but it fights Bob’s plan to make the new Mini the main work machine. | Only if Bob keeps two machines. |
Hardening a local Desktop on the work Mini — Docker backend, write-root, toolsets off, approvals.mode: manual — still leaves file reads and shell escape hatches. That is a lab posture, not “the Mini is safe.” Official production guidance is the opposite: put the agent in a container or in the cloud, do not run it on the host you care about.
The LM Studio / Qwen teaching lab assumed a Mini-local Desktop talking to a localhost model. Cloud Desktop cannot see that model unless we later add a private tunnel — which is a new hole. The lab stays off, on a separate non-daily profile, and never becomes production Roxy.
Asked after the docs pass, not before. Route: Nous Portal, model anthropic/claude-opus-4.8, completed. Brief and raw answer live under ~/.hermes/work/roxy-desktop-security-consult/.
Opus’s default, one sentence: ship Roxy as Telegram-only with no Hermes runtime on Bob’s Mini, keep Dropbox Inbox for large files, and defer Desktop until a client-only Cloud mode is confirmed to run zero local tools.
It called option 2 theater. It said do not migrate iMac work or secrets onto the Mini while any local Hermes runtime exists. It said the local-Qwen lab must not share Bob’s daily profile.
James closed the unknown. Desktop is Cloud/Nous. That is the honest second choice, and it is the live setup. Telegram stays as the other door. Do not rip Desktop out.
Only leftover: delete an unused local install if one is still on disk, so the app cannot be flipped back to a Mini-local agent. The chrome leak is accepted residual, not a reason to stall the iMac move.
| Rule | |
|---|---|
| MUST | Brain stays on Cloud/Nous. Do not point Desktop at a local Mini runtime. |
| SHOULD | Delete any leftover unused local install. Keep Telegram as the other door. |
| LATER | Optional chrome hygiene (repo_scan_enabled: false, no Screen Recording grant). Recheck the public macOS installer before any future reinstall. |
| NEVER | Local Desktop + stock/smart approvals on the work Mini. Do not call approvals a sandbox. Do not wire the Qwen lab to daily Roxy. Do not add a Mini tunnel just to save the lab. |