[BUG] Claude Desktop (Linux): 100% CPU busy-loop before UI paint when isHardwareAccelerationDisabled=true; flag auto-persisted after GPU crash permanently bricks the app

[BUG] Claude Desktop: busy-loop at 100% CPU before UI paint when isHardwareAccelerationDisabled=true — flag is auto-persisted after a GPU crash, permanently bricking the app

Environment

• Claude Desktop 1.19367.0 (Linux build, Electron), Ubuntu 24.04, kernel 6.14
• NVIDIA RTX 4090, driver 580.159.03, X11 session
• Launched with --proxy-server=http://<lan-proxy>:37409 (proxy verified reachable; not a factor — reproduced identically without it)

Summary

After a GPU driver hiccup, the app showed a "Graphics Error" dialog and auto-persisted
isHardwareAccelerationDisabled/AutoDisabled: true into claude_desktop_config.json.
From then on, every launch enters a main-process busy loop at 100% CPU before the
logger is initialized and before the window paints. Because the flag is persisted and
the UI never appears, the user has no way to re-enable hardware acceleration — the app is
permanently unusable until the JSON is edited by hand. On our machine the runaway process
eventually contributed to a full system freeze requiring a hard reboot.

Evidence

• With the flag set: main process (the browser process itself, main thread) pins one core.

strace shows a tight unthrottled loop reading /proc/self/stat, /proc/stat,
/proc/<selfpid>/status (~950k syscalls in 24 s) — looks like a process-metrics
sampler (pidusage-style) re-arming with no delay. Zero writes to logs/main.log
(last entries remain from the previous run), so the loop runs before logging init.

• Bisected the entire profile directory file-by-file: with the identical profile and

only isHardwareAccelerationDisabled/AutoDisabled flipped back to false, the app
starts normally (idle CPU ~0–5%, logs written, window paints). Flipping them to true
reproduces the spin deterministically. All other profile content (Cookies, Local
Storage, IndexedDB, session dirs, caches, sentry, MCP config) was exonerated by graft
tests onto a fresh profile.

Repro

1. On Linux, set in ~/.config/Claude/claude_desktop_config.json:

"isHardwareAccelerationDisabled": true, "isHardwareAccelerationAutoDisabled": true

1. Launch Claude Desktop.
2. Observe: no window (or blank), main process at 100% CPU, logs/main.log never written.

Expected

• Disabled hardware acceleration should fall back to software rendering, not busy-loop.
• Any metrics/sampling loop should be throttled (setTimeout/backoff), never spin.
• An auto-persisted degradation flag that can render the app unlaunchable should have a

recovery path (e.g., auto-clear after N failed launches, or a --reset-gpu CLI flag).

Secondary issue found while debugging (separate, minor)

If an MCP server's command is not found in PATH (e.g., npx installed via nvm is not
in the desktop session's PATH after reboot), the desktop's MCP server manager appears to
respawn the failing server aggressively. Suggest: resolve command existence once, log an
error, and back off, rather than hot-looping respawns. Workaround: absolute path in
claude_desktop_config.json.