Windows: local 'CLI bridge' stays cold after brief network blip; app restart does not recover it, only full reinstall/reboot

Open 💬 0 comments Opened Jul 3, 2026 by samm-ingran

Environment

  • OS: Windows 11 Pro, build 10.0.26200
  • Claude Desktop version: auto-updated from 1.15962.0 to 1.17377.2 on the same day, incident happened after the update
  • Locale/timezone: America/El_Salvador (UTC-6)

Summary
After a brief local-network disruption (the office DNS/DHCP server briefly went unreachable due to an unrelated infrastructure event, ~a few minutes), the desktop app's local "CLI bridge" (the component connecting the renderer UI to the local session/agent engine) got stuck permanently cold. The renderer repeatedly logged the same QueryClient error every 1-5 minutes for 45+ minutes straight:

QueryClient error: "empty slash-command list (cold CLI bridge)"

First occurrence: 2026-07-02 18:27:15
Last occurrence before reinstall: 2026-07-02 19:12:22
(log source: %APPDATA%\Claude\logs\claude.ai-web.log)

What did NOT fix it

  • A full clean app quit + relaunch (confirmed in main.log: beforeQuit at 19:11:29, "Starting app" at 19:11:34) did not fix it — the same cold-bridge error reappeared 12 seconds later at 19:12:22.
  • Switching the machine's active network connection to a different network (mobile hotspot tethering) did not help either.

What did fix it

  • Rebooting the OS (twice) and reinstalling the Windows app, roughly 90 minutes after the initial disruption.
  • Faster workaround found afterward: killing the Claude.exe process via Task Manager (instead of a graceful app restart) and relaunching also clears it, no reinstall needed.

Impact
This happened at a genuinely bad moment: the local session was mid-task on a physical server the user needed to act on, and had no way to interact with the assistant for over an hour.

Hypothesis
A persistent connection between the renderer/bridge and the local session engine is left in a half-open state at the exact moment the underlying network hiccups. Since the OS does not reap a dead TCP connection until the default keepalive timeout (~2h on Windows), and the app's own reconnect logic does not appear to force-recreate this connection on a normal app restart (only killing the OS process did), the bridge stays cold indefinitely instead of self-healing.

Suggested fix
The CLI-bridge client should run its own short-timeout heartbeat/health check and force-recreate the underlying connection whenever a heartbeat fails, especially on OS network-change events or after an app relaunch, rather than trusting stale OS-level socket state.

Logs (claude.ai-web.log and main.log covering 2026-07-02 18:00-19:15 local time) available on request.

View original on GitHub ↗