Claude Desktop (Windows) — steady kernel nonpaged-pool memory leak tied to app runtime, causes full system hang after ~1.5-2 hours

• Windows 11 Pro, build 10.0.26200
• Claude Desktop, sideload-MSIX package pzs8sxrjxfjjc (Developer signature),

ProductVersion 1.22209.3 — confirmed reproduced on a completely fresh
download+install performed 2026-07-20 (full uninstall, then reinstall from
a freshly downloaded installer, same morning), so this is current as of
today, not a stale cached build.

• Bundled claude-code engine version 2.1.209 (unchanged by the reinstall)
• App data relocated via NTFS junctions to a second drive (AppData\Roaming\Claude

and %USERPROFILE%\.claude both junctioned to D:\), done ~2026-07-18. Confirmed
NOT the root cause (see "Ruled out" below — full reinstall did not change the
leak rate, and junctions were verified intact throughout).

Symptom:
System hangs completely — mouse cursor still moves, but keyboard input, Ctrl+Alt+Del
and Ctrl+Shift+Esc are all unresponsive. Only recovery is a hard power-off. Started
occurring ~2026-07-16/17, no hangs before that date on the same machine.

Root cause (confirmed by direct measurement):
Windows kernel nonpaged pool (PoolNonpagedBytes, sampled via
Win32_PerfFormattedData_PerfOS_Memory over WMI, once/minute) grows steadily at
approximately 128-155 MB/minute. This growth is tied strictly to how long the
Claude Desktop APPLICATION has been running (not OS uptime):

• With the app fully closed, growth nearly stops: ~1.7 MB/min over a 15-minute

window (vs. ~130+ MB/min while running).

• Reopening the app immediately resumes the ~130-150 MB/min growth.
• The growth occurs even with an empty sidebar (zero open chat sessions).
• Already-leaked pool is never released back except by a full reboot.

Mechanism (measured):
The main claude.exe process pegs ~100-103% of a single CPU core continuously
(measured over clean 30-second windows on the process's own PID). During that
window it issues approximately 50,000-56,000 kernel calls/second (IOOther
counter), while disk I/O stays near zero (~5-10 ops/sec) and open-handle count
is flat (no handle leak — ruled out separately). Dividing the pool growth rate
by the call rate gives ~37-41 bytes of nonpaged pool leaked per call, consistent
across multiple independent measurement sessions on different days.

Within the process, exactly one thread is pegged (~96-100% CPU, Running state)
while all other threads are idle/waiting. A system-wide scan of IOOther deltas
across every running process found no other process with a matching counter-
party rate — i.e. this thread appears to be repeatedly polling/calling into some
IPC channel (named pipe or similar) with nobody listening on the other end, and
each failed/round-tripped call costs ~40 bytes of nonpaged pool that is never
freed.

IMPORTANT — narrowed to the Electron MAIN process specifically (2026-07-20):
Verified via Win32_Process.CommandLine that among the ~13 running claude.exe
processes, the one pegged at 98-100% of a core is the bare
"...\Claude.exe" invocation with NO --type=... argument — i.e. Electron's
main/browser process, not any --type=renderer or --type=gpu-process child.
Sibling --type=gpu-process and --type=renderer processes for the same
window showed only moderate, plausible CPU use (~30-40%) during the same
measurement window and were not investigated further as suspects.

Also confirmed the same measurement window included a completely separate,
freshly-launched terminal invocation of the underlying claude-code CLI engine
(same binary family, launched directly via a cmd wrapper, with NO Electron
parent process at all) sitting idle at its prompt. That process showed
consistently ~0% CPU over two independent 20-second and 25-second windows
(vs. the Electron main process's stable 92-100% during the exact same windows).
This strongly localizes the bug to the Electron/Desktop-app main-process layer
of the Windows build, not to the shared claude-code engine itself.

Ruled out, with evidence (each tested independently, rate unchanged in all cases):

1. Specific chat sessions / sidebar content — rate persists with sidebar fully

emptied (all sessions deleted).

1. A user-created scheduled skill/routine ("check-phone-tasks", MCP

scheduled-tasks server) — rate persists after fully deleting the routine,
its scheduler seed-file entry, and all its session transcripts; confirmed the
routine did not silently resurrect across two full app restarts.

1. Local MCP servers — none are configured (checked claude_desktop_config.json

and running processes); all integrations are HTTPS-based remote connectors,
no local stdio MCP server processes exist to leak a local IPC channel.

1. "Remote Control" feature — disabled via Settings (not just closing a

session): 128.8 MB/min measured before and after, no change.

1. Disk health, pending Windows Update, GPU/display driver version, and OS

power-management idle settings (VIDEOIDLE/ASPM/USB-suspend/DISKIDLE) — all
tested independently (disabled/updated/checked), none affected the rate.

1. A FULL uninstall + clean reinstall of the Claude Desktop app — done in full

(not Repair, not Reset). Confirmed the reinstalled app's data junctions were
intact and pointed at the same data. Measured a clean 10-minute post-reinstall
window: ~141 MB/min — same rate as before the reinstall.

1. Chrome/WebView2 helper processes (used by the in-app browser-preview

feature) — force-killed all chrome.exe (7) and msedgewebview2.exe (18)
processes. msedgewebview2.exe processes auto-respawned within seconds
(evidently kept warm by the app itself); leak rate unchanged (~120-140 MB/min)
before and after.

1. Hardware acceleration is a weak/unlikely candidate: the separate GPU process

stays calm (~17% CPU) throughout, while the spinning thread lives in the MAIN
process, not the GPU process.

Reproduction:
Install/run Claude Desktop on Windows and leave it open (idle is sufficient, no
specific user action required). Sample PoolNonpagedBytes via WMI/PerfMon once
per minute. Growth is linear, reproducible every session, and independent of
reboot count or session history.

Impact:
On a 16 GB RAM machine, this exhausts available nonpaged pool and hard-hangs the
system after roughly 1.5-2 hours of continuous app runtime, requiring a hard
power-off (no software-level recovery works once it happens).

Data available on request: multi-day CSV samples (timestamp, system uptime, app
uptime, free RAM, commit, PoolNonpagedBytes, PoolPagedBytes, per minute), plus
per-process syscall-rate snapshots and relevant Windows Event Log excerpts.