[BUG] Windows MSIX Desktop: main process spins at 100% of a core with 150k-330k file 'other' I/O ops/s; kernel pool grows to ~9.4 GB (FMfn/File/IoFE), not the fswatch-probe/NtFC variant

Summary

On Windows, the Electron main process of MSIX-packaged Claude Desktop spins at ~100% of one core and issues 150,000 to 330,000 "other" file I/O operations per second (per-process IO Other Operations/sec), while the kernel paged/nonpaged pool grows to ~9.4 GB, dominated by the FMfn, File and IoFE tags. The machine ends up memory-starved: tool calls in every open Claude Code session slow down from ~2 s to 80 s median, and sessions get torn down by the Desktop inactivity watchdog (timed out after ~1000s of inactivity).

This looks related to, but distinct from, the existing reports:

• #95489 / #94198: there the source is the bundled engine (fswatch-probe-* retries, tag NtFC), fixed by CLAUDE_CODE_TMPDIR. Here the engines are quiet (~130 to 360 ops/s each), %LOCALAPPDATA%\Temp\claude is a plain folder, not a junction, CLAUDE_CODE_TMPDIR is unset, and NtFC is not among the top tags.
• #45889 (closed, locked): same "main process" attribution, but that trace showed ~47k file creates per 3 s. Here the main process does almost no creates (see ETW below): the operations are non-create control/query operations.
• #92583: orphaned Bash processes can also inflate the pool; ruled out as the main driver here (see below).

Environment

• Windows 11 Home, build 10.0.26200.9457, 32 GB RAM (16 GB soldered + 16 GB SO-DIMM, the max for this laptop)
• Claude Desktop MSIX Claude_2.7032.0.0_x64, bundled engines 2.1.275 and 2.1.280
• 30 to 40 Claude Code sessions (code tab) open at the same time
• File system minifilters (fltmc filters): all Microsoft — bindflt, UCPD, WdFilter, storqosflt, wcifs, gameflt, CldFlt, bfs, FileCrypt, luafv, UnionFS, npsvctrig, Wof, FileInfo
• CoworkVMService running (AUTO_START); no WSL workload during the measurements
• Fast Startup was ON, so the kernel had not been reinitialized for 6 days despite daily "shutdowns" (same finding as #94198); now disabled

Measurements (2026-09-24, same app instance, started 08:28)

| Metric | Value |
|---|---|
| Desktop main process CPU (5 s samples) | 94 to 100% of one core, continuously from ~10:45 to 14:23 |
| Main process IO Other Operations/sec (5 to 10 s deltas) | 146,296 (13:15), 327,170 (14:23) |
| Main process IO Read Operations/sec | ~217 |
| Next highest claude.exe (engines) | 128 to 412 ops/s each |
| System-wide File Control Operations/sec | 370,000 to 380,000 (normal baseline ~500) |
| Kernel pool (Win32_PerfFormattedData_PerfOS_Memory) | nonpaged 3.46 → 3.72 GB, paged 5.30 → 5.72 GB between ~10:45 and ~13:15 |

Top pool tags (NtQuerySystemInformation(SystemPoolTagInformation), outstanding allocs = allocs − frees), 11:00:

| Tag | Pool | Size | Outstanding |
|---|---|---|---|
| FMfn | paged | 2,777 MB | 8,049,471 |
| File | nonpaged | 1,531 MB | 4,015,480 |
| IoFE | nonpaged | 533 MB | 7,753,332 |
| Toke | paged | 337 MB | 162,521 |
| IoNm | paged | 285 MB | 2,008,979 |

The number of outstanding File objects (4.0 M) is far above the system-wide handle count (222,377), so these file objects are referenced without open handles.

ETW (Microsoft-Windows-Kernel-File, keywords 0x90 = CREATE + FILENAME, 3 s)

47,563 events. The Desktop main process issued only 113 creates in 3 s, and all claude.exe processes together issued 792. So the main process's 150k to 330k ops/s are not file opens. They are control/query operations on objects it already holds, or on pipes. I could not capture stacks to go further.

Ruled out

• Third-party file system filters: none are loaded.
• Defender: Git, .claude, the projects folder, and the bash, claude, git and node processes are all excluded; MsMpEng runs at ~3,600 ops/s.
• Orphaned Bash processes (#92583): the system-wide handle count stays at ~222k, and no process holds millions of handles.
• An engine update: the engine went from 2.1.275 to 2.1.280 on 09-24 at 08:28, but the slowdown started on 09-22.

Possibly related, secondary observation

The Desktop utility process accumulates conhost.exe children (session PTYs): 170 by 14:00, created at ~28 per hour since 08:00, none released, plus idle powershell.exe children with no children of their own. They only account for ~0.34 GB private, but the accumulation never stops.

Impact

• bash -c true takes 3 to 8 s. Each hook adds seconds, and hooks exceed their timeout, which means they are silently skipped.
• Median Bash tool duration went from ~2 s (09-21) to 80 s (09-24).
• 13 sessions were killed by the Desktop inactivity watchdog on 09-23/09-24, versus none from 09-17 to 09-22.

What should happen

The Desktop main process should not spin on file control operations, and the kernel pool should not grow without bound while it runs.

Workaround so far

A true Restart clears the pool. Disabling Fast Startup makes Shutdown clear it too. I have not found a way to stop the spin other than quitting Desktop. I will add a comment with post-restart measurements: whether the spin comes back, and after how long.