# 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.