Claude Desktop (Windows): renderer process CPU/memory runaway with many open sessions — app-wide UI stutter, ~5min cold-start delay

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 22, 2026

Bug: Claude Desktop (Windows) renderer process CPU/memory runaway when many sessions are open — app-wide UI stutter, ~5min cold-start delay

Environment

  • App: Claude Desktop (Windows), package Claude_1.24012.1.0_x64 (appVersion 1.24012.1)
  • OS: Windows 11 Pro, build 10.0.26200
  • Hardware: 16GB RAM (8×2GB DIMMs, all slots populated), 18 logical CPU cores, dual SSD (no HDD)
  • Account has ~35 saved chat sessions (mix of active/idle), several running concurrently across multiple projects

Symptom

  1. UI lag/stutter is confined specifically to the Claude Desktop window — other applications on the same machine (browser, IDE, Office) run smoothly throughout, and system-wide CPU stays under ~30%.
  2. On a fresh reboot, the Claude Desktop window itself takes ~5 minutes to appear/become responsive, before any user interaction.
  3. Started suddenly (no corresponding system/driver change), persists across multiple reboots, and is unaffected by closing other unrelated applications — isolating the cause to Claude Desktop itself rather than general system load.

Root cause (identified via direct process monitoring, psutil)

  • One specific Claude.exe --type=renderer child process is pinned at 150–245% CPU continuously (sustained over 15+ minutes of observation, verified with repeated sampling) — roughly 2.5 cores' worth of load. Against an 18-core system this stays under Task Manager's aggregate ~30% total and is easy to miss.
  • The same renderer process's RSS memory grows continuously at roughly 7 MB/s (observed climbing ~2.8GB → ~3.8GB over ~15 minutes without plateauing) — consistent with an active leak, not a one-time allocation.
  • Meanwhile the account has roughly 10–25 other Claude.exe child processes open simultaneously (one per open session/tab, many left idle in the background). Only the one active renderer showed the runaway CPU/memory pattern — the others sat at normal (tens to a few hundred MB, low CPU) levels.
  • The cold-boot 5-minute delay (before any user interaction) suggests the runaway is triggered early — likely during session-list restore/render at launch with a large number of stored sessions — rather than purely accumulating from long uptime.

Repro steps

  1. Have 25+ saved chat sessions in the account (mix of projects/worktrees).
  2. Launch Claude Desktop (works both after a fresh reboot and from a normal restart).
  3. Observe: (a) a multi-minute delay before the window appears/responds; (b) once open, sustained stutter confined to that window.
  4. Cross-check with Task Manager / Get-Process Claude — aggregate CPU% looks unremarkable, but sorting by per-process CPU/handle growth over time (e.g. via psutil, sampling cpu_percent() and memory_info().rss every few seconds) surfaces exactly one --type=renderer process pinned high and growing.

Diagnostic note

Windows Task Manager's system-wide CPU/Memory summary did not surface this — the leak/CPU spike is isolated to a single process among dozens and averages out. A short per-process sampling script (delta CPU% + memory growth rate over a few seconds) reliably reproduces the finding. Happy to share the diagnostic script if useful.

View original on GitHub ↗