personal-agent-os/memory-systems/agent-os/04_projects/hermes-host-stack/status.md

Hermes Host Stack (this PC) — Status

The Hermes host infrastructure on C:\Users\fight\AppData\Local\HermesHost after the 2026-10-02 re-home: launchers, scheduled tasks, gateway, Web UI, tunnel, and the update path. Created 2026-10-02 by jimmy.

Naming rule (from Tony, 2026-10-02)

• VeriPath must never run a task. VeriPath is a product; host infrastructure is not VeriPath.
• The host stack lives in ...\AppData\Local\HermesHost (renamed from a VeriPath-named folder that in fact held only Hermes launchers), and its scheduled tasks live under the \Hermes\ task path. \VeriPath\ now holds zero tasks.

Components (verified 2026-10-02)

Piece	Where	State
Gateway (jimmy + leonard, multiplexed)	durable launcher	running, Telegram connected
Web UI	127.0.0.1:8787 (PID 25100)	LISTENING
Cloudflare tunnel	HermesHost\cloudflared.ps1	running
\Hermes\Cloudflared_Tunnel	scheduled task	Running
\Hermes\Hermes_WebUI	scheduled task	Running
\Hermes\Hermes_Gateway_leonard	scheduled task	Ready — retired (flag in place)
Launchers	HermesHost\{webui,leonard,cloudflared}.ps1, regis-forward.py, run-hidden.vbs	active

• Launchers poll for .disabled flag files every 1 s, so stopping a service is a clean child-tree teardown rather than a kill. HermesHost\leonard.disabled is still present (leonard retired).
• HERMES_DISABLE_LAZY_INSTALLS=1 in webui.ps1 is required — without it the Web UI crash-loops on ModuleNotFoundError: No module named 'api' at server.py:102.

The update saga ("why can't I update Hermes?")

• Symptom: hermes update aborted with another Hermes process is using this installation; desktop.log showed venv-blocked: 3 process(es) hold the install.
• Cause: three S4U scheduled tasks under \VeriPath\ (created 2026-09-26) kept a remote-access stack — and its venv holders — alive; a non-elevated scan could not read those foreign-account processes, which is why PID-to-profile mapping kept failing.
• Resolution: flag the launchers off (leonard.disabled, webui.disabled) → clean teardown → hermes update -y → applied, now v0.21.5+5794.g9a71d5a (upstream 9a71d5a8).
• Then re-homed: elevated finish-rehome-elevated.ps1 (UAC approved) moved the tasks to \Hermes\, dropped the temporary VeriPath→HermesHost junction, and unregistered the stale Hermes_Gateway_jimmy task.
• Postmortem instrument: HermesHost\diagnostics\update_postmortem.py → diagnostics\20261002T173838Z\postmortem.md (adversarially reviewed; five citations and one causal claim were corrected in that pass).

Open items

• CLI launcher republish still failing. hermes doctor reports CLI exposure failed: source launcher publication failed; hermes\bin\hermes.exe is dated 2026-08-31 (pre-update). The running image holds the file, so it cannot be overwritten in place. A one-shot Startup shim (Hermes_RepublishLauncher.cmd) is queued and has not fired yet — the last interactive logon was 2026-10-02 08:08, before the shim existed. Impact is limited: PATH resolves hermes to the venv shim (hermes-agent\venv\Scripts\hermes) first.
• Windows update-abort receipts still warn gateway_restart.incomplete = true / "mixed sys.modules".
• Gateway cron delivery is broken (unrelated to the update) → 01_Wiki/hermes-cron-delivery-gateway-config.
• Parked, low priority: state.db WAL checkpoint, 3 npm advisory groups, hermes setup API keys.

Owner / status

Owner: jimmy (Hermes profile jimmy). Status: active. Created 2026-10-02.