hermes - 💡(How to fix) Fix Optionally update the remote backend when updating the desktop app

Feature request: optionally update the remote backend when updating the desktop

Problem

The desktop app and the Hermes backend are separate installs. When they live on the same machine, one "Update Hermes" covers both. But for remote users (desktop on the laptop, backend on a VM/box via the remote gateway), updating the desktop does not update the backend.

This silently breaks things when a change lands in tui_gateway/server.py (the backend). Real example: the per-session profile-routing fixes (#39921/#39993) live in the backend. A user updated the desktop, the VM stayed old, and new chats silently landed in the wrong profile with no obvious cause — a multi-day debugging session before we realized the backend was stale. (Mitigated now by the contract-skew warning in #40017, but the user still has to update the remote by hand.)

Original ask (community report): "hermes desktop updates automatically trigger updates via remote gateway to update backend at the same time? maybe an optional thing."

Why it's feasible (plumbing already exists)

• POST /api/hermes/update already runs hermes update (git pull + reinstall) on whatever backend serves the request (hermes_cli/web_server.py → _spawn_hermes_action(["update"], ...)).
• The desktop's API calls are connection/profile-routed (hermes:api → ensureBackend(request.profile) in electron/main.cjs), so the same call can target a remote backend.
• There's already a backend restart hook: POST /api/hermes/gateway/restart.
• The desktop already exposes updateHermes() (apps/desktop/src/hermes.ts) hitting that endpoint — it's just not chained to the desktop self-update flow (applyUpdates in apps/desktop/src/store/updates.ts).

So the pieces are: desktop self-update (local binary) + POST /api/hermes/update (remote) + restart. Today only the first runs on "Update Hermes."

Proposed behavior

An opt-in setting, e.g. "Also update the remote backend when updating Hermes." When enabled and the active connection is remote, the update flow additionally:

1. Detects the distinct remote backend(s) in play (global-remote URL and/or per-profile-remote overrides) — skip when the backend is local (self-update already covers it).
2. For each remote backend: POST /api/hermes/update, poll the action status, then restart the dashboard so the new code loads.
3. Reconnect and verify (e.g. the backend now reports the expected DESKTOP_BACKEND_CONTRACT).

Gate behind a confirm — this runs git pull + reinstall on another machine.

Design gotchas (why opt-in, not automatic)

• Remote-only: never double-update the local backend (self-update handles it).
• Multiple backends: per-profile-remote / multi-dashboard setups have several remote backends on different ports — iterate distinct remote URLs; one git pull on a shared repo updates all, but each dashboard process needs its own restart.
• Reachability / auth: remote may be down, OAuth-gated, or the user may lack update rights. Fail gracefully → show the manual command (git pull && uv pip install -e . / hermes update), never hang.
• Restart coordination: pull → restart → reconnect, with a clear progress UI; the active session/WS will drop during restart.
• Trust/safety: auto-running a remote git pull+reinstall from a desktop click is a meaningful action; require explicit opt-in + confirm.
• Branch alignment: the remote should update to a commit compatible with the desktop build (mirror the existing self-update branch logic).

Acceptance criteria

• New opt-in setting (default off).
• On "Update Hermes" with the setting on + a remote connection: remote backend(s) update + restart, with progress + graceful failure → manual fallback.
• No-op / unchanged for local backends and single-machine users.
• Handles multiple remote backends.
• Post-update contract check confirms alignment (ties into #40017).

Interim mitigation (already shipped)

#40017 bumps the GUI↔backend contract so a desktop pointed at a stale backend now shows a "Backend out of date" warning instead of silently misrouting — so even without this feature, the skew is no longer invisible.