v0.6.2 Chat input never reaches gateway — "loding" spinner hangs forever (complete unusability)

[sunnysails]

Hermes Desktop v0.6.2 — Chat input never reaches gateway, "loding" spinner hangs indefinitely (complete unusability)

Summary

Sending any chat message in the desktop chat panel leaves the UI stuck on the "loding" spinner forever. The message never reaches the gateway. No requests leave the renderer. This is not a slow response or partial failure — the desktop chat input is functionally dead.

After fully restarting the Electron app (kill all hermes-agent.exe processes, including main, gpu, utility, renderer), the symptom reproduces on a fresh boot. The bug makes the application completely unusable for chat, which is the application's primary feature.

Environment

• OS: Windows 10 (build unknown)
• Hermes Desktop version: 0.6.2 (latest, released 2026-06-18 per release page)
• Installer path: C:\Users\sunnysails\AppData\Local\Programs\hermes-desktop\hermes-agent.exe
• Hermes CLI (separate install): C:\Users\sunnysails\.hermes\hermes-agent\ (source checkout)
• Hermes Agent backend: working — see "Backend is healthy" below
• User data dir: C:\Users\sunnysails\AppData\Roaming\hermes-desktop\

Reproduction

1. Fresh start: Start-Process 'C:\Users\sunnysails\AppData\Local\Programs\hermes-desktop\hermes-agent.exe'
2. Wait ~60s for the desktop UI to fully render
3. Click the chat input, type any message (e.g. ping), press Enter
4. Observe: loding spinner appears, never resolves, no response, no error toast
5. Repeat for 27+ minutes: same result every time

Diagnosis Evidence

1. Backend (gateway) is healthy

Direct curl against the local API server (the gateway that Hermes Desktop spawns to handle requests):

$ curl -s -m 5 http://127.0.0.1:8642/health
{"status": "ok", "platform": "hermes-agent"}

The gateway process is the long-running one:

pid=18040 cmd="C:\Users\sunnysails\AppData\Roaming\uv\python\cpython-3.11-windows-x86_64-none\python.exe"  -m hermes_cli.main gateway

Process pythonw.exe -m hermes_cli.main gateway (pid 35028) is its parent wrapper. This tree is stable and serving requests correctly when called via curl.

2. Desktop messages never reach state.db

The ~/.hermes/state.db SQLite store is the authoritative record of every conversation. Querying it across 27 minutes of attempts:

SELECT source, COUNT(*) FROM sessions WHERE started_at > 1781767800 GROUP BY source;
-- Result:
-- cli | 1
-- (zero api_server / desktop-originated sessions)

SELECT id, source, datetime(started_at,'unixepoch','localtime'), message_count
FROM sessions WHERE started_at > 1781766000 ORDER BY started_at DESC;
-- Result:
-- 20260618_154010_9f6a68 | cli | 2026-06-18 15:42:42 | 69

The single session in that window is source=cli — that's the terminal session I have running concurrently (which works fine). There are zero sessions originating from Hermes Desktop.

3. Renderer is idle, not starving

Sampled CPU on the real renderer process (--type=renderer, pid 48696) over 15 seconds while idle (no chat activity):

t=0   CPU=30.875  WS_MB=182.7
t=5   CPU=30.891  WS_MB=179.9   delta_CPU=0.016   delta_WS_MB=-2.8
t=15  CPU=30.891  WS_MB=179.9   delta_CPU=0.016   delta_WS_MB=-2.8

CPU is essentially flat over 15s — the renderer is not running a runaway 3D render loop or animation. WS even shrank slightly (GC kicked in). The chat input area simply never fires a submit event, or the submit handler fails before any IPC call to main reaches the gateway.

4. Other process anomalies

While the desktop is open and idle:

Id    CPUs    WS_MB  Type                              Responding
2868  0.12    85.5   --type=utility ... AudioService   True
15700 30.27   271    --type=gpu-process                True
23760 0.12    51.8   --type=utility ... NetworkService True
29488 6.25    174.9  (main, no --type= flag)           True
48696 30.72   188.3  --type=renderer                   True

• --type=gpu-process (pid 15700) uses 30+ seconds of CPU while idle — abnormally high for an idle desktop. Suggests the GPU process is in a busy spin (likely 3D scene claw3d.ts + GLB assets apartment.glb/building1.glb/atm.glb/biz_man.glb continuously redrawing), or a hung Mojo IPC await on the GPU side.
• Main (pid 29488) shows CPU growth without bound (6.25s after launch, climbing) — main may be waiting on the renderer but the renderer isn't responding.
• All five processes report Responding=True, but Electron's Responding flag only proves the Win32 message pump is alive, not that the main thread is making progress. This is a known Electron pitfall.

5. Full kill + restart does not fix it

I performed a full restart twice:

• Attempt 1: killed all 5 hermes-agent.exe processes, restarted from Start Menu. After 60s the UI rendered. Chat send → same hang.
• Attempt 2: killed only main (pid 37056) + renderer (pid 31688) at the OS level via Stop-Process -Force. New 4-process tree spawned at 16:00:19. Gateway tree (pythonw + python) survived. Chat send → same hang.

The bug reproduces 100% of the time after a fresh boot.

6. No error logs

C:\Users\sunnysails\AppData\Roaming\hermes-desktop\logs\updater.log only contains auto-update events, no application errors. There is no other log file in the user-data dir that would surface a renderer-side stack trace. No console output is captured for the packaged Electron app, so the JavaScript error (if any) is swallowed.

7. Configuration that may be relevant

• ~/.hermes/config.yaml has platforms.api_server.enabled: true, port: 8642, key: hermes-local-key-2026.
• No OAuth login completed for desktop — desktop is running in local mode only.
• ~/.hermes/hermes-agent/ is a source checkout (no venv subdirectory), so the gateway spawned by desktop runs from source. Possibly relevant: the desktop binary at AppData\Local\Programs\hermes-desktop\ is the Electron wrapper, separate from the Python source tree.

Workaround (until this is fixed)

Don't use Hermes Desktop for chat. Use the Hermes CLI directly — it bypasses the Electron renderer entirely and works reliably:

hermes chat

This is the path every other integration (CLI, Telegram, API server) uses, and is unaffected by this renderer deadlock.

Hypothesis

The renderer (or its Mojo IPC bridge to main) is in a state where the chat submit handler either:

1. Never binds to the input element after the chat panel mounts, or
2. The IPC message from renderer→main→gateway is dispatched but main's await on renderer completion is never woken.

Combined with the abnormal GPU process CPU (30+s, idle), this looks like a deadlock between the renderer's chat IPC handler and the GPU process's Mojo pipe — possibly because both are waiting on each other through the same Mojo channel. A Web Worker for the 3D scene, or moving the chat submit handler out of the main renderer thread, would likely unblock this.

Related existing issues

• Feedback: Read aloud, skill persistence, timeouts, and freezing #539 "Feedback: Read aloud, skill persistence, timeouts, and freezing"
• Remote mode cannot chat even though /health and /v1/chat/completions work via local SSH tunnel #575 "Remote mode cannot chat even though /health and /v1/chat/completions work"
• Remote Gateway connection loop — "Could Not Connect to Hermes Gateway" #520 "Remote Gateway connection loop — Could Not Connect to Hermes Gateway"
• Task list progress UI freezes on first task while agent continues #637 "Task list progress UI freezes on first task while agent continues" (closed/not-planned)

None of the above match this exact symptom (renderer idle, messages never leave process), but the pattern of "UI shows loding, no traffic leaves the renderer" recurs across reports.

[sunnysails]

Update: confirmed regression from v0.6.1 → v0.6.2

After filing this issue, I confirmed via the auto-updater log (%AppData%\hermes-desktop\logs\updater.log) that v0.6.1 was the previous installed version (installed 2026-06-14 09:27 UTC), and v0.6.2 was downloaded today at 07:19 UTC and replaced the binary at C:\Users\sunnysails\AppData\Local\Programs\hermes-desktop\hermes-agent.exe (file mtime 12:59 local).

v0.6.1 behavior (morning, before upgrade): a full desktop restart reliably handled the FIRST chat message; only subsequent messages or new sessions in the same session would hang.

v0.6.2 behavior (current): even the first message after a fresh restart hangs forever with no traffic leaving the renderer (verified: 0 new rows in state.db across multiple 27-minute windows; renderer PID 48696 idle at delta_CPU=0.016 over 15s; GPU PID 15700 abnormally high at 30+ CPU seconds while idle).

This is a clear regression introduced between 325e892 (v0.6.2 tag) and the previous v0.6.1 release. Bisecting against those two commits would likely isolate the offending change — candidates based on the v0.6.2 release notes are:

• The chat input / submit handler rewrite for the new "slash command" feature (slash command registry may have replaced the plain submit handler and the plain path is no longer wired up)
• The chat picker / "session-scoped model" change (the model picker IPC path was reworked — cli.py → IPC → gateway/CLI fallback)
• Profile switcher (added v0.6.2) — if profile switcher state is read during chat submit and reads block on an uninitialized handle, every submit blocks

Please prioritize this — chat is the application's primary feature and v0.6.2 has been live for <24h.

[sunnysails]

Follow-up: "hung" and "extremely slow" are the same bug at different severity

After the initial report, the desktop did start responding again without any restart. Across the next ~30 minutes I observed:

• Renderer WS growth while idle: 645 MB → 798 MB over ~1.5 hours (PID 36356), never releasing
• Gateway churn: the gateway subprocess on port 8642 died and respawned at least once during this window (PID 53304 → 18196), even though the Electron main process never restarted
• Per-message latency: 3 chat turns over a single api_server session took 4–5 minutes each to return (gap_p50 = 267.8s between assistant responses). The UI does eventually unblock — it's not a hard hang — but the lag is unusable for interactive work.

This looks like the same root cause as the original report (renderer-side IPC / 3D scene contention), just at a milder severity than the earlier dead-lock case. The renderer is consuming memory it never frees and IPC handlers are being preempted by GPU work (the GPU process still pegs at 30+ CPU seconds while idle — confirmed again just now).

So the symptom spectrum for v0.6.2 is:

Severity	Symptom
Worst	hard hang — message never reaches gateway, loding spinner forever (original report)
Mild	message eventually returns after 4–5 minutes, renderer memory grows unboundedly

Both are caused by the same v0.6.2 renderer regression. Bisecting v0.6.1 ↔ v0.6.2 (commit 325e892) is the right next step — the candidates in the v0.6.2 release notes are still the slash command registry change, the chat-picker / model-override rework, and the new profile switcher.

[sunnysails]

Root cause narrowed: GPU process pinned at 100%+ CPU, chat submit is queued behind GPU compositing

After the "extremely slow" report, I confirmed via sustained sampling that the GPU process (--type=gpu-process, currently PID 36356) consumes ~100-121% of one CPU core continuously, even when no 3D page is open and no chat is in flight. 10-second window:

t=2s  CPU=903.81s  WS=480MB
t=4s  CPU=905.33s  (+1.52 / 2s = 76%)
t=6s  CPU=907.61s  (+2.28 / 2s = 114%)
t=8s  CPU=909.77s  (+2.16 / 2s = 108%)
t=10s CPU=912.19s  (+2.42 / 2s = 121%)

The user explicitly notes: "I haven't opened the 3D page in over 10 minutes" — so this is not the claw3d.ts RAF render loop. Something in the GPU process / Chromium compositor is in a tight loop even with the 3D scene hidden.

The user also observes the chat UI showing two separate loding spinners simultaneously in the same window (likely chat panel + sidebar/recent-sessions area), while one previously-completed turn's content remains visible. This is consistent with the chat submit event being queued behind GPU compositing — the loding UI is the "submitted but waiting for IPC response" state, and since GPU work never yields, the queue never drains until a lucky scheduling window.

The fix on the desktop side should probably be one of:

1. Audit the GPU process for any non-yielding loops (could be a timer that runs more frequently than requestAnimationFrame, a setInterval without throttling, or a worker thread spinning)
2. Move chat IPC submit handling off the renderer main thread so it doesn't compete with compositing
3. Add a disable-gpu-process or disable-3d-scene flag for users who don't need the 3D scene

Bisecting v0.6.1 → v0.6.2 (commit 325e892) is still the right next step to identify what regressed. The v0.6.2 release notes mention a chat-picker IPC rework, slash command registry, and profile switcher — any of these could have introduced a non-yielding loop in the GPU process or the renderer main thread that the 3D scene alone would not have caused in v0.6.1.

[sunnysails]

Additional reproduction evidence (Windows 10, 2026-06-18)

Hit the same symptoms today. Sharing my full evidence chain — also found a likely trigger that #718 doesn't mention.

Process state (5 hermes-agent.exe, created within 1 second of each other):

PID      WorkingSet    Created
15472    164 MB        2026-06-18 16:50:19
36356    533 MB        2026-06-18 16:50:19
50544     41 MB        2026-06-18 16:50:19
44740    508 MB        2026-06-18 16:50:19
47708     46 MB        2026-06-18 16:50:20

Same 1-second creation window confirms these are workers from one session, not separate conversations.

Gateway port 8642 healthy, but…

netstat shows gateway listening cleanly. CLI conversations work fine. Only desktop stays stuck on loading.

NEW evidence: Background review mode loop

While the desktop session was running, agent.log shows a background review entered a deadlock state. From 18:53:58 onwards, every tool call (except memory/skill) was rejected with:

Background review denied non-whitelisted tool: search_files. Only memory/skill tools are allowed.

This persisted across 10+ tool calls over ~7 minutes without ever exiting:

18:53:58  execute_code denied
18:54:45  search_files denied
18:59:41  search_files denied
18:59:48  execute_code denied
19:00:41  patch denied
19:01:07  skill_manage failed (different error, not denied)
19:01:20  skill_manage failed

Suspected trigger

Right before the loop, two things happened:

1. memory tool was called and failed with: "Memory at 1,326/1,375 chars. Adding this entry (232 chars) would exceed the limit."
2. Several skill_manage calls failed with: "Found 131 matches for old_string" (skill content had grown too large to patch safely)

The session entered a background-review state, but the state never exits because the review can't complete its task (whitelist is too narrow to actually finish the review).

Hypothesis

The 800MB+ workers are likely the background review worker accumulating failed tool calls in memory without ever GC'ing. The desktop session itself is stuck because the gateway routes new desktop messages to a worker that's blocked in this review state.

Suggested fix directions

1. Background review mode needs an automatic exit condition (timeout, or successful tool call, or max-iterations)
2. Whitelist in review mode should at least include read-only tools (search_files, read_file) so the review can actually complete
3. Memory/skill capacity limits (1,375 chars) should trigger a clear user-facing warning BEFORE the agent starts thrashing in review mode
4. Each worker should have a max-runtime guard so stuck workers get killed, not pile up to 800MB

Workaround tested

taskkill /PID 36356 /F && taskkill /PID 44740 /F should release the two stuck workers. Haven't confirmed full recovery yet but this is the next step per the analysis.

Repro path summary

Desktop conversation → triggers memory tool → memory near capacity (1,326/1,375) → agent tries to write/refactor memory → enters background review → review can't complete (whitelist too narrow) → worker thread accumulates → 800MB+ RSS → gateway routes new desktop messages to stuck worker → desktop loading forever.

---

CC @fathah — happy to attach raw logs (agent-20260618-bug.log, gateway-20260618-bug.log) if useful for diagnosis.

[Plangto]

Same for me on windows 11