Safety, Remote & Recovery — ปลอดภัย ต่อระยะไกล กู้คืนได้Safety, Remote & Recovery — Safe Hands, Remote Hosts, and Getting Back Up

🤔 If the agent you installed six posts ago ran a recursive delete on the wrong directory at two in the morning — what, exactly, would have stopped it? And if the app refused to open the next morning, where would you look first?

The previous post, #6 Automation & Agents, left you with an agent that works while you are away — cron jobs, Bot Mode routines, subagents steered mid-flight. An agent that works unattended is precisely the one that needs three things it did not need on day one: a guardrail it cannot talk its way past, a clear answer to "which machine is this command running on", and a way back when something breaks.

The one-line answer: three dials — the approvals mode, the write guards and hardline blocklist, and the execution boundary — plus a recovery ladder that starts at hermes logs desktop and ends at three uninstall scopes. This is the last post of the series and the hands-on counterpart of #4 Security: that post owns the threat model; this one owns what you click, type and check.

1. Three Dials That Keep a Desktop Agent Safe

A desktop agent is kept safe by three settings you can name. approvals.mode — smart, manual or off — decides whether a human sees a dangerous command before it runs. The write guards and the hardline blocklist refuse a small set of things regardless of that mode. And the execution boundary decides which machine actually runs the command. Every other control on the Safety page is a refinement of one of those three.^[1]

Dial one — the approvals mode

Before a shell command runs, Hermes checks it against a list of dangerous patterns — recursive deletes, chmod 777, mkfs, SQL DROP, piping a download into a shell, killing the gateway, and about thirty more. A match goes to the approval layer, and approvals.mode says what happens there.^[1] In smart (the default), an auxiliary LLM rates the risk: low-risk commands are auto-approved for that one command, genuinely dangerous ones are auto-denied, and uncertain cases escalate to you. manual asks you every time. off disables the checks — the docs call it equivalent to running with --yolo.^[1]

Two companions matter as much as the mode itself. Headless contexts have their own switch — cron_mode, single_query_mode and unattended_mode all default to deny, so a cron job or a webhook session that trips a dangerous pattern is blocked rather than left waiting for a human who is not there.^[1] And the approval prompt has a clock: if nobody answers within timeout (300 seconds by default), the command is denied. The docs' word for that is fail-closed, and it is the property I check first on any machine that holds real credentials.^[1]

Dial two — write guards and the hardline blocklist

Some refusals do not depend on the mode at all. write_file and patch are hard-blocked from credential stores — ~/.ssh/, ~/.aws/, ~/.kube/, /etc/sudoers, ~/.netrc, Hermes's own auth.json and .env, mcp-tokens/, pairing/, and any .env file anywhere on disk — with no prompt and no override from the chat. If you want a fence rather than a denylist, HERMES_WRITE_SAFE_ROOT limits those two tools to the directories you list.^[1] Above that sits the hardline blocklist: rm -rf / and its variants, the bash fork bomb, mkfs on a mounted root device, dd onto a physical disk, and piping an untrusted URL into sh. It trips before the approval layer sees the command, survives --yolo, approvals.mode: off, cron's approve mode and an "allow always" click, and has no override flag.^[1]

Between the two is the dial you actually turn: approvals.deny, a list of glob patterns that block matching commands unconditionally — before YOLO and before mode: off are even consulted. The docs describe it as yolo-with-exceptions: let the agent do everything, except these specific things, ever.^[1]

Dial three — the execution boundary

The third dial is the one people forget, because it is not on the Safety page. terminal.backend says where shell commands run: local and ssh keep the dangerous-command check on, while docker, singularity, modal, daytona and vercel_sandbox skip it, because the container itself is the boundary.^[1] A Remote gateway connection moves further than a backend does. The desktop app's own README states it in one sentence I will quote rather than paraphrase: "In remote mode the gateway host is the execution boundary: agent tools, terminal commands, and file operations run against the remote Hermes host, not the computer displaying the Desktop UI."^[9] Section 4 is the procedure for exactly that.

💡 Where the theory lives: the repository's security policy names exactly one load-bearing boundary, and §2.2 states it in the sentence that frames all three dials — "The only security boundary against an adversarial LLM is the operating system." The approval gate, redaction and every scanner are named there as heuristics: useful, but not containment.^[8] #4 Security walks that policy layer by layer and covers the case that hit closest to home for those of us in Thailand — a Hermes instance in YOLO mode, running unattended inside a government network. I will not retell it here; read it there, then come back and turn the dials.

2. Procedure — Set Approvals and Deny Rules

Set the mode on Settings → Safety, add deny rules for the commands you never want to see, leave the 300-second timeout alone so it fails closed, find the YOLO toggle in the status bar so you recognise it when it is on, and then test with a command you know is flagged. One honesty note first: the official docs list Safety among the per-profile settings pages but never describe what it holds, so the steps below name the configuration keys — the page mirrors them.^[2]

1. Open Settings with Cmd/Ctrl+, and choose Safety. With two or more profiles, an Applies to chip row appears at the top of the page; the default follows the active profile, and switching the app's active profile resets it, so pick the profile you mean before you touch anything.^[2]
2. Choose the approval mode — smart, manual or off. My own rule: manual on any machine that holds real credentials until I trust a workflow, smart for everyday work, and off only inside a container I can throw away.^[1]
3. If you would rather edit the file, the same keys live under approvals: in ~/.hermes/config.yaml. Changes take effect immediately — the config cache is keyed on the file's modification time — so no session restart is needed.^[1]
4. Add deny rules for the things that must never run, whatever the mode. Quote every pattern — a bare leading * is a YAML alias and fails to parse — and remember they match case-insensitively against the whole command text and apply to host-reaching backends only.^[1]
5. Leave timeout: 300. When a prompt goes unanswered for that long, the command is denied; a lower number makes a walk to the coffee machine safer, not riskier.^[1]
6. Find the YOLO toggle. It sits in the status bar along the bottom of the chat, and it is per session — "flip YOLO on or off for just this session (matching the TUI)".^[2] The same switch has three other spellings: /yolo in the chat, hermes --yolo at launch, or HERMES_YOLO_MODE=1 in the environment. When it is on the toggle prints ⚡ YOLO mode ON — all commands auto-approved. Use with caution., every later session opens with the red banner ⚠ YOLO mode — all approval prompts bypassed, and a ⚠ YOLO fragment sits in the status bar until you turn it off.^[1]
7. Test it — in manual mode, because smart may judge a scratch-directory delete low-risk and wave it through. Ask the agent to delete a scratch directory recursively; rm -rf /tmp/hermes-test is a recursive delete, one of the flagged patterns. Watch for the approval prompt: the pattern name, the exact command, and the four choices once, session, always, deny. The docs show the CLI rendering; the Desktop presents the same decision. If the command ran without asking, YOLO is on or the mode is off.^[1] (v0.21.0's release notes list a dry-run approval checker for the CLI, but it is not in the CLI reference yet, so I test in the chat.^[10])
8. Optional: after a few weeks, run hermes approvals suggest. It mines approved commands from the session database into allowlist proposals, applies nothing unless you pass --apply, and never proposes a destructive class — rm -rf build/ approved a hundred times still yields no rm entry.^[1]

The approvals: block, verbatim from the Security page:

# ~/.hermes/config.yaml
approvals:
  mode: smart                     # smart | manual | off
  timeout: 300                    # seconds to wait for user response (default: 300)
  cron_mode: deny                 # deny | approve — what cron jobs do when they hit a dangerous command
  single_query_mode: deny         # deny | approve — what single-query (-q) sessions do on a dangerous command
  unattended_mode: deny           # deny | approve — what webhook/API sessions do on a dangerous command
  mcp_reload_confirm: true        # /reload-mcp asks before invalidating the MCP tool cache
  destructive_slash_confirm: true # /clear, /new, /reset, /undo prompt before discarding state

And the deny rules, using the docs' own three examples:

# ~/.hermes/config.yaml — consulted before --yolo, /yolo and approvals.mode: off
approvals:
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

The execution backend

The third dial is set in ~/.hermes/config.yaml under terminal.backend. I could find no Desktop page that documents a control for it, so I edit the file and start a new session afterwards. The seven values are the ones in the Security page's comparison table:^[1]

# ~/.hermes/config.yaml
terminal:
  backend: docker    # local | ssh | docker | singularity | modal | daytona | vercel_sandbox
                     # local and ssh keep the dangerous-command check; the other five skip it

3. Checkpoints and /rollback — a Way Back Before You Need One

Checkpoints are the agent's undo for the filesystem, and they are opt-in: the default is off, because the shadow store costs disk over time and most users never type /rollback. Turn them on with checkpoints.enabled: true in config.yaml (or hermes chat --checkpoints for one CLI session), and Hermes snapshots the project before write_file, patch and destructive shell commands; /rollback <N> restores the files and undoes the last conversation turn so the agent's context matches the disk again.^[6]

# ~/.hermes/config.yaml — opt-in; the shadow store lives in ~/.hermes/checkpoints/store/
checkpoints:
  enabled: true
  max_snapshots: 20           # per project
  max_total_size_mb: 500      # oldest commits are dropped past this
  max_file_size_mb: 10        # larger files are skipped, not snapshotted

The mechanics are worth thirty seconds, because they explain the limits. Every project shares one bare git repository under ~/.hermes/checkpoints/store/ — your real .git is never touched — and the agent takes at most one checkpoint per directory per turn. Triggers are the file tools plus rm, rmdir, cp, install, mv, sed -i, truncate, dd, shred, output redirects and git reset/clean/checkout. Directories over 50,000 files and the root and home directories are skipped, and if git is not on PATH, checkpoints silently disable themselves.^[6]

/rollback                 # list checkpoints with change stats
/rollback diff 1          # preview what changed since checkpoint 1 — do this first
/rollback 1               # restore checkpoint 1, keeping your own hand-edits
/rollback 1 --all         # full restore, overwriting your hand-edits too
/rollback 1 src/app.py    # restore a single file
hermes checkpoints        # store size, project count, per-project breakdown
hermes checkpoints prune  # sweep orphans and enforce the size cap

Two details make this safer than it sounds. A restore first takes a pre-rollback snapshot, so you can undo the undo. And /rollback <N> restores only the files Hermes itself wrote — every successful write records a content hash in an agent-write ledger, and a file you edited afterwards is skipped and listed, unless you add --all.^[6] The checkpoints page documents /rollback as an in-session slash command and shows the CLI's output; the Desktop chat is a session on the same backend, and I found nothing that says it behaves differently there — so type it in the chat.

4. Procedure — Attach the Desktop to a Hermes on Another Machine

On the host, put an auth provider in place and run hermes serve --host 0.0.0.0 --port 9119; binding to a non-loopback address engages the auth gate, so a backend without a provider does not simply open up. In the Desktop, Settings → Gateways → Add connection, pick Remote gateway (URL plus a session token or Nous Portal OAuth) or SSH (your key; the app opens the tunnel and adopts a dashboard token), press Test, then open a session — and remember that from that moment every command runs on that host.^[2][3]

On the host

1. Choose the provider by where the host lives. Username/password is for a trusted LAN or a VPN such as Tailscale only; for anything reachable beyond your own machine the docs prefer OAuth through Nous Portal — register the backend with hermes dashboard register and sign in from the app with "Sign in with Nous Research". A self-hosted OIDC provider works the same way.^[2]
2. For the username/password path, append the three variables to ~/.hermes/.env exactly as the docs show, then start the backend. Keep it under systemd or tmux: the app attaches to it and never starts it for you, and a messaging gateway is a separate process you run beside it.^[2]
3. Verify the gate before you hand the URL to anyone. curl the status endpoint from your laptop: it should print true and include "basic" (or your OAuth provider).^[2]

# on the remote host
cat >> ~/.hermes/.env <<'EOF'
HERMES_DASHBOARD_BASIC_AUTH_USERNAME=admin
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD=choose-a-strong-password
# Recommended: a stable signing secret so sessions survive restarts.
# Without it a random key is generated per boot and you'll be logged out
# on every restart.
HERMES_DASHBOARD_BASIC_AUTH_SECRET=$(openssl rand -base64 32)
EOF
chmod 600 ~/.hermes/.env

# the non-loopback bind engages the auth gate
hermes serve --host 0.0.0.0 --port 9119

# from your laptop: is the gate really on?
curl -s http://<host>:9119/api/status | jq '.auth_required, .auth_providers'

In the Desktop

1. Open Settings → Gateways (Cmd/Ctrl+,, then Gateways; or the plug button at the right end of the profile rail, "Connect another Hermes gateway…"; or Cmd/Ctrl+K and type Gateways). Scroll to Registered gateways and click Add connection.^[3]
2. Pick the kind. Remote gateway: a unique device name (up to 64 characters, unique case-insensitively), the Gateway URL of the running backend such as http://homelab.lan:9119, and Session token or OAuth. SSH: the name plus one composite field in user@host:22 form; your SSH key is used, and the app opens the tunnel, starts the dashboard on the far side and adopts a dashboard token over it.^[3]
3. Click Save connection, then Test on the new row. Test probes both the HTTP and the WebSocket leg, so the "Reachable" toast means chat will actually work — not merely that the host pinged.^[3]
4. Optionally Make primary. Primary is the registry's fallback for multi-gateway calls that do not name a gateway; it does not switch the current Sessions workspace, and if you remove it the app falls back to the local entry.^[3]
5. Switch to the gateway from the Sessions sidebar — a named gateway selector appears once more than one is registered — pick a profile discovered on it, and open a session. Files, tools, channels, cron and memory are now scoped to that (gateway, profile), and the execution-boundary sentence from section 1 applies in full: the laptop is a screen.^[3][9]

Two shortcuts. HERMES_DESKTOP_REMOTE_URL, set before launch, overrides the in-app URL — you still sign in from the Gateways page.^[2] And on a single-remote setup the Connection mode → Remote gateway control on the same page — Remote URL, Sign in, Save and reconnect — does the same job without the registry; you stay signed in across restarts only when HERMES_DASHBOARD_BASIC_AUTH_SECRET is set.^[2]

5. Reference Table — When It Breaks

Read the log first, then the table. Every row below is sourced to a docs page, a release note or an issue I re-read on 7 September 2026; symptoms I could not source are not here.

6. Logs and Diagnostics — Where to Read, What to Send, and to Whom

All logs live in ~/.hermes/logs/ (or <profile>/logs/ for a non-default profile), and hermes logs reads five of them by name: agent (the default — API calls, tool dispatch, session lifecycle), errors (warnings and errors only), gateway (messaging), gui (dashboard, TUI-gateway, PTY bridge and WebSocket events) and desktop (the Electron app — boot, backend spawn output, recent Python tracebacks).^[4] For anything the app does at startup, desktop is where I look first.

hermes logs desktop                  # the Electron app: boot, backend spawn, Python tracebacks
hermes logs gui -f                   # follow the dashboard / TUI-gateway / websocket events
hermes logs errors -n 200            # warnings and errors only, last 200 lines
hermes logs gateway --since 1h       # messaging gateway, last hour
hermes logs list                     # every log file with its size
hermes doctor --fix                  # diagnose config and dependencies; repair what it can
hermes debug share --local           # print the report to the terminal instead of uploading it

When a turn fails, the Desktop shows an error card that names the failing layer — provider, custom endpoint, streaming, authentication, billing, gateway, local runtime or disk — with actions matched to it: Retry, Switch provider, Open logs (on a remote or Cloud connection it reads Open Desktop logs, because the agent's logs live on the other machine), Send diagnostics and Copy error details.^[2] Send diagnostics is opt-in each time: it asks for explicit consent, uploads a redacted bundle through the same pipeline as hermes debug share --nous, is viewable by Nous staff only, auto-deletes after 14 days, and hands you a private link for your support thread. On a remote connection the backend bundles its own logs and the local Desktop log rides alongside.^[2] If you would rather see what leaves your machine, hermes debug share --local prints the same report to the terminal; uploads are redacted by default, and --no-redact exists for a reason I have never needed.^[4]

None of this is a background upload. The bundle exists only when you press the button and confirm the consent prompt; the docs describe it as an explicit action, not telemetry.^[2]

💡 A bug and a vulnerability go to different doors: a crash goes in the diagnostics bundle or a public issue. A vulnerability does not. The security policy asks that you report privately, through GitHub Security Advisories or [email protected], says in bold that you should not open public issues for it and that there is no bug bounty, and sets the coordinated-disclosure window at 90 days or until a fix ships, whichever comes first.^[8]

7. Update, and the Three Ways to Uninstall

The app checks for updates in the background and offers a one-click update when one is ready. With more than one update target — a remote gateway, or several registered ones — every update affordance (Update now on the About panel, ⌘K → Update Hermes, the update-ready toast) updates everything in a fixed order: the connected backend first, then every other eligible registered gateway (Hermes Cloud entries are platform-managed and skipped), and the desktop app itself last, because applying the client update relaunches the app. After any backend update the app re-checks its own version and offers Update desktop app if the GUI is behind.^[2]

A safe update, in order

1. hermes update --check — fetches and compares against origin/main; nothing is modified and no gateway restarts.^[5]
2. hermes update --plan — prints what would happen: the install kind, every running Hermes service with its supervisor and running version, and how each will be restarted. A manually launched hermes serve powering a remote Desktop appears here too, with its recorded bind address; the update stops it before the code swap and relaunches it on the same host and port, so the Desktop reconnects instead of stranding.^[5]
3. Decide on the backup. The default pre-update snapshot is quick — pairing data, cron jobs, config.yaml, .env, auth.json and other runtime state, taken per profile. For a machine you care about, run hermes update --backup for a full zip of HERMES_HOME, or set updates.pre_update_backup: full once.^[5]
4. On Windows, close Hermes Desktop first. hermes update refuses while another hermes.exe holds the venv's executable open — most commonly the Desktop's spawned backend — and a second guard refuses to touch the venv while any process runs from its interpreter; that one is not bypassed by --force.^[5]
5. Now press Update now in About (or ⌘K → Update Hermes). The Desktop's updater runs hermes update --keep-stash: local source edits are stashed and never re-applied, and the log prints the exact git stash apply to bring them back. Expect the app to relaunch last.^[5]
6. Verify. hermes --version; then ~/.hermes/logs/update_receipts/latest.json, which records the plan, each step, what was skipped and why, and the final fleet version matrix — a gateway still on pre-update code fails the run with the exact restart command. If the Desktop rebuild failed you see ⚠ Update partially complete; the previous app is untouched, and hermes desktop retries the rebuild.^[5]
7. If the new version is worse, roll back: in the checkout, git checkout <commit-hash> then uv pip install -e ".[all]", restart the gateway, and run hermes config check to catch options the older version does not recognise.^[5]

hermes update --check      # am I behind origin/main? — changes nothing
hermes update --plan       # what would restart, and how
hermes update --backup     # full HERMES_HOME zip first, then update
hermes --version
cat ~/.hermes/logs/update_receipts/latest.json

# rollback, from the checkout
cd ~/.hermes/hermes-agent
git log --oneline -10
git checkout <commit-hash>
uv pip install -e ".[all]"
hermes gateway restart
hermes config check

The three ways to uninstall

Settings → About → Danger zone offers three scopes, and the terminal has the same three. Uninstall Chat GUI only removes the desktop app and its own data; the agent, your config and your chats stay. Uninstall GUI + agent, keep my data removes the app and the agent but keeps config, chats and secrets for a reinstall. Uninstall everything removes the app, the agent and all user data. The app closes to finish the job, because the cleanup has to remove the running bundle and its own venv; and on a GUI-only client attached to a remote backend, the two agent-removing options are hidden.^[2]

hermes uninstall --gui --dry-run   # print what would be removed, change nothing
hermes uninstall --gui             # the desktop app and its userData only — agent, config, chats stay
hermes uninstall                   # GUI + agent; ~/.hermes (config, sessions, secrets) stays
hermes uninstall --full            # everything, including ~/.hermes — the laptop you are handing back

Before the last one, hermes backup captures the whole ~/.hermes including credentials, while hermes profile export packs one profile with the keys stripped by design — an export alone is not a full backup.^[5] And a note for source checkouts: hermes uninstall --gui also removes the workspace node_modules and apps/desktop/{dist,release}, which hermes desktop rebuilds.^[2]

8. Summary — Closing the Series

Seven posts ago, #1 Install & First Run opened with a map of the series — install, local models, profiles, a council, skills and MCP, automation, and this post. Read backwards, the map is a trust curve: each post handed the agent a little more — a model, a personality, tools, a schedule — and this one is where you decide how much of that trust is enforced by the operating system rather than by hope. Set the three dials before you set the cron job, not after.

What I would do this week, on the machine you actually use: put approvals.mode: manual and two deny rules in place and trigger one flagged command to see the prompt; turn checkpoints on for one project and run /rollback diff once; run hermes update --check and read desktop.log once while nothing is wrong, so that on the day something is wrong you already know what normal looks like. If a second machine is in the picture, make it a dedicated backend and attach to it — then everything the agent touches lives there.

The hands-on series ends here; the analytical one does not. #4 Security owns the threat model and the incident record, and #10 Desktop & Fleet owns what an organisation needs before twenty laptops attach to one backend. Everything above is what one person does at one desk, with one hand on each dial.