Desktop: New sessions frozen/blank — infinite backend restart loop on Windows

[robbyslmt]

Bug Description

New chat sessions in the Hermes Desktop app are completely frozen — blank chat area, can't type, can't send messages, no error shown. Existing (older) sessions continue to work fine. The issue is caused by the desktop's hermes serve backend restarting in an infinite loop.

Environment

• Hermes Agent: v0.18.2 (2026.7.7.2) · upstream 4281151
• OS: Windows 10 (Microsoft Windows Version 10.0.26200.8737)
• Python: 3.11.14
• Install method: git
• Custom provider: custom:naraya (mimo-v2.5-pro-hermes)

Symptoms

1. Opening a new session shows a blank/frozen chat area
2. Composer input is disabled — can't type or send
3. No error message or overlay is shown
4. Older sessions display and respond normally
5. Gateway (hermes gateway run) works fine independently (Telegram sessions work)

Key Evidence from Logs

gui.log — WebSocket connections keep dying and reconnecting

# 441 WebSocket reconnects logged
# 279 event loop stalls logged
# Pattern: connect → stall → disconnect → reconnect every 30-90 seconds

04:42:29 ws accepted → 04:43:03 ws closed (26 msgs, 34 sec!, code=1006)
04:44:50 ws accepted → 04:47:12 ws closed (86 msgs, 2 min, code=1006)
04:47:48 ws accepted → 04:49:09 ws closed (29 msgs, 90 sec!, code=1006)

Every WebSocket close triggers a full backend restart (visible as "Mounted plugin API routes" + "Desktop cron scheduler started" + new ws accepted cycle).

desktop.log — Infinite update loop

# 89 "Updating Hermes" triggers
# 51 backend restarts (HERMES_BACKEND_READY)
# 3 "Desktop boot failed" events

[hermes] [boot] Hermes backend is ready. Finalizing desktop startup
[hermes] [updates] restart: Updating Hermes — this window will close...
[hermes] Hermes backend exited (SIGTERM)
[hermes] [boot] An update is finishing — Hermes will start automatically...
[hermes] [boot] An update is finishing — Hermes will start automatically...
[hermes] [boot] An update is finishing — Hermes will start automatically...
# ...repeats endlessly

The .update_check file shows {"behind": 0, "ver": "0.18.2"} — the checkout IS up to date. git rev-parse HEAD and git rev-parse origin/main return the same SHA. Yet the desktop keeps triggering hermes-setup.exe --update --branch main.

gui.log — Event loop stalls (GIL pressure)

WARNING hermes_cli.web_server: event loop stalled 7.0s (GIL pressure suspected)
WARNING hermes_cli.web_server: event loop stalled 8.5s (GIL pressure suspected)
WARNING hermes_cli.web_server: event loop stalled 14.2s (GIL pressure suspected)
WARNING hermes_cli.web_server: event loop stalled 20.7s (GIL pressure suspected)

agent.log — Model fallback triggered during boot

run_agent: OpenAI client created (agent_init, shared=True) provider=custom model=mimo-v2.5-hermes
# (20 seconds later)
run_agent: OpenAI client created (agent_init, shared=True) provider=nous model=tencent/hy3:free
# (40 seconds later)
run_agent: OpenAI client created (switch_model, shared=True) provider=custom:naraya model=mimo-v2.5-pro-hermes

The desktop initially loads with mimo-v2.5-hermes (no -pro), fails, falls back to tencent/hy3:free, then eventually switches to the correct mimo-v2.5-pro-hermes. This suggests the desktop may be reading a stale model name.

desktop.log — Dashboard token 404

[hermes] [boot] could not read served dashboard token (Hermes backend): 404:
  {"error":"Headless backend (hermes serve): web UI disabled — use `hermes dashboard` for the browser UI."}

This appears on every boot but the desktop falls back to the spawn token.

What Was Tried (didn't help)

1. ✗ Cleared .update_check and .update_exit_code — update loop persists
2. ✗ Cleared Electron cache directories — issue persists
3. ✗ Killed all Hermes processes and restarted — issue persists
4. ✗ Confirmed git rev-parse HEAD === git rev-parse origin/main — checkout is current
5. ✗ Cleared Local Storage, Session Storage, Cache, Code Cache, GPUCache, blob_storage, partition data — issue persists
6. ✗ Gateway restart — issue persists

Hypothesis

The desktop's update detection (checkUpdates() in electron/main.ts) is triggering even though the checkout is up to date. The resolveBehindCount function at line ~2166 compares SHAs for the SSH remote path, but the origin is HTTPS. The non-SSH path (line ~2176) does git fetch + git rev-list --count which may return a stale or non-zero count due to shallow clone or detached state, causing behind > 0 even when current.

Each "update" triggers a full backend restart (hermes-setup.exe --update), which kills the running hermes serve process, drops all WebSocket connections, and makes the desktop reinitialize. During this gap, new sessions can't be created because the frontend's gateway connection is in a reconnecting state.

Additional Context

• 25 active cron jobs configured (may contribute to GIL pressure)
• Session context had grown to 151K+ tokens (may contribute to event loop stalls)
• code=1006 WebSocket closures = abnormal closure (no close frame received)
• detached_sessions=1-2 on each WebSocket close = sessions orphaned during reconnect

Logs Available

Full logs available at ~/AppData/Local/hermes/logs/:

• desktop.log — 5.3MB
• gui.log — 430KB
• agent.log — 350KB
• gateway.log — 750KB
• errors.log — 450KB

[alt-glitch]

This was generated by AI during triage.

Related: #52378 (CLOSED) reported the same Windows Desktop self-update infinite-loop mechanism (behind:0 yet the process still enters the update branch, repeated hermes-setup.exe --update restarts). This is a fresh recurrence of that mechanism, so keeping it open rather than marking it a duplicate of a closed item. Also related to #62671 (Windows Desktop crash-loop, different mechanism — WAL DB lock). The reporter's resolveBehindCount HTTPS-path hypothesis (phantom behind>0 on a current checkout) is the most likely root cause to verify.

[teknium1]

Thanks for the detailed logs. An automated hermes-sweeper review found that current main already contains fixes for both mechanisms described here.

• apps/desktop/electron/main.ts:2197-2214 now detects shallow/no-merge-base checkouts and resolves update status by comparing HEAD and origin/<branch> SHAs; apps/desktop/electron/update-count.ts:18-28 returns behind: 0 when those SHAs match. This is covered by apps/desktop/electron/update-count.test.ts:22-33 and was added in a6485bddb855536e60baa7074573a820d3d1ee76.
• apps/desktop/electron/main.ts:2599-2608 writes an updater-in-progress marker immediately after spawning the updater, and main.ts:6330-6336 blocks backend spawning while that update is live. This closes the reconnect/backend-respawn window described in the report; it was added in d00c7193c12087067bc4d475cb1811709580241b.
• The related Windows: 自动更新陷入无限循环，重复弹出管理员命令行窗口 (update loop) #52378 discussion correctly identified the updater-loop family; the current marker gate additionally protects the backend handoff race rather than allowing repeated backend restarts.

No release tag was verified for these commits.

[robbyslmt]

Both referenced fix commits are already present in the reporter's checkout, yet the issue persists:

$ git merge-base --is-ancestor a6485bddb855536e60baa7074573a820d3d1ee76 HEAD && echo "Fix #1 PRESENT"
Fix #1 PRESENT

$ git merge-base --is-ancestor d00c7193c12087067bc4d475cb1811709580241b HEAD && echo "Fix #2 PRESENT"  
Fix #2 PRESENT

$ git log --oneline -1
4281151ae test(gateway): cover effective context budget

$ hermes --version
Hermes Agent v0.18.2 (2026.7.7.2) · upstream 4281151a

The resolveBehindCount SHA-compare fix (#1) is present and git rev-parse HEAD === git rev-parse origin/main (both return 4281151ae859241351ba14d8c7682dc67ff4c126). The updater marker pre-write (#2) is also present.

Despite both fixes being applied, the desktop log still shows 89 "Updating Hermes" triggers and 51 backend restarts (HERMES_BACKEND_READY events) in a single session. The .update_check file correctly reports {"behind": 0}, yet the desktop keeps spawning hermes-setup.exe --update --branch main.

This suggests a third mechanism not covered by these two fixes — possibly the Electron-side update check (the hermes:updates:check IPC handler at main.ts:8596) is computing a non-zero behind value through a different code path than checkUpdates(), or the frontend is re-triggering the update overlay based on stale state from a previous boot cycle.

The WebSocket connection pattern shows the desktop restarting the backend every 30-90 seconds, with event loop stalled warnings (GIL pressure) preceding each disconnect. The code=1006 WebSocket closures cascade into full backend restarts rather than just reconnecting the socket.

Additional data point: 279 event loop stalled warnings in gui.log, with stalls ranging from 5-21 seconds. The backend may be unable to respond to health checks during these stalls, triggering the desktop to assume the backend is dead and restart it.