[BUG] Cowork VM leaks NtFC (NTFS FCB) NonPaged Pool at 12-16 GB/h; two full RAM-exhaustion cycles in one evening, reboot required (re #45921)

Preflight Checklist

• [x] I have searched existing issues — #45921 describes the same leak but is labeled invalid and has had no maintainer response since 2026-04-09, so I am filing a fresh, fully-instrumented report
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

Environment

• OS: Windows 11 25H2, build 26200.8655
• RAM: 32 GB
• Claude Desktop: 2.1.161
• Trigger: Claude Desktop with Cowork VM (claudevm.bundle) running

What's Wrong?

While the Cowork VM is running, the kernel NonPaged Pool grows at 12–16.5 GB/h under pool tag NtFC (NTFS File Control Blocks) until physical RAM and the commit limit are exhausted and the machine becomes unusable. Closing the app only stops further growth; the leaked pool is never reclaimed without a reboot (it is kernel memory, not process memory).

Yesterday evening this machine went through two complete exhaustion cycles in under four hours. Timeline from automated 30-minute pool-tag snapshots (NtQuerySystemInformation(SystemPoolTagInformation)), local time:

| Local time | NtFC NonPaged |
|---|---|
| 20:07 | 8.41 GB |
| 21:10 | 25.81 GB → RAM exhausted, reboot #1 |
| 21:58 | ~0 (clean after boot) |
| 22:29 | 7.83 GB |
| 23:00 | 16.35 GB |
| 23:31 | 24.89 GB |
| 23:57 | forced reboot #2 |

Growth rate in the second cycle: 7.83 → 24.89 GB in 62 minutes ≈ 16.5 GB/h.

A prior incident on 2026-06-09/10 on the same machine showed the identical signature: NtFC 7 → 28.6 GB over an evening, reboot, regrowth to 21 GB, reboot; a 12-minute Claude Desktop run on the fresh boot left 3.27 GB of NtFC behind, flat after the app was closed.

Why this happens (observed mechanism)

The Cowork VM churns large numbers of unique-name temp files (.wvm-tmp-*). Each unique file name forces NTFS to allocate a new File Control Block in NonPaged Pool, and something in the VM's file handling keeps those FCBs referenced, so they are never freed. This matches the WinDbg crash bucket AV_Ntfs!NtfsInitializeIrpContextInternal reported by another user in #45921 (10+ BSODs in 24 days).

Steps to Reproduce

1. Windows 11 machine, NTFS system volume
2. Launch Claude Desktop and let the Cowork VM start (idle is sufficient; no active conversation needed per multiple reports in #45921)
3. Watch NonPaged Pool / tag NtFC (poolmon, or NtQuerySystemInformation(22))
4. NtFC grows continuously at GB/h scale; closing the app stops growth but releases nothing

Expected Behavior

Temp-file handling in the Cowork VM should not permanently pin NTFS FCBs in kernel NonPaged Pool; closing the app should leave no residual kernel allocation.

Severity / impact

• Kernel-level leak: full RAM exhaustion on 32 GB machines in ~1.5–2 h, reboot is the only recovery
• Reproduced independently by at least five users in #45921 (16 GB and 32 GB machines, Win10/Win11), including BSODs
• #45921 has been open since 2026-04-09 with no maintainer response and carries an invalid label (apparently from triage automation), so it may not be in anyone's queue — please either re-triage that issue or track via this one

References

• #45921 (original report, ~13 GB/h, plus five independent confirmations)
• WinDbg !analyze -v failure bucket from #45921: AV_Ntfs!NtfsInitializeIrpContextInternal