Cowork VM causes persistent kernel pool leak (Toke/File/SeAt) leading to system-wide UI degradation on Windows

Bug Report: Cowork VM causes persistent kernel pool leak leading to system-wide UI degradation

Environment

• OS: Windows 11 Pro 10.0.26200
• Hardware: Corsair One (AMD Ryzen 9 24-core, RTX 5080, 64 GB DDR5, dual NVMe)
• Claude Desktop: v1.40609.0.0 (WindowsApps MSIX package)
• Display: 5120×1440 @ 143 Hz

Summary

Claude Desktop's Cowork VM (via CoworkVMService, wcifs/bindflt minifilters, and WSL2 infrastructure) leaks kernel pool objects — primarily access tokens (Toke), file objects (File), and security attributes (SeAt) — at a sustained rate of ~2 Toke/s and ~11 File/s during normal use. These objects are driver-allocated (charged to no user-mode process) and persist until reboot.

After 3–4 days of uptime, paged pool exceeds ~5 GB and the Windows object manager / security subsystem slows measurably, causing 50–200 ms stalls in window dragging, Alt+Tab, and general input responsiveness — even with 30+ GB of free RAM. The only remediation is a full system restart.

Related Issues

• anthropics/claude-code#55361 — Cowork → wcifs/bindflt FCB retention (~2 GB/h)
• anthropics/claude-code#45889, #48813 — similar pool/handle leak reports
• microsoft/WSL#40804 — WSL2 VHDX → NtFC leak on 26200.x builds

Our case differs in tag signature (File + Toke rather than NtFC) but the mechanism — minifilter-allocated pool objects never freed — is the same family.

Evidence

1. The leak is driver-allocated, not user-mode

Measured via NtQuerySystemInformation class 22 (SystemPoolTagInformation):

Paged pool charged to ALL user-mode processes:  0.29 GB
System paged pool total:                        7.97 GB
UNACCOUNTED (driver-allocated):                 7.68 GB

No amount of stopping user-mode processes reclaims this memory.

2. Leak rate and object counts

After 7+ days uptime:

| Pool tag | Live objects | Pool consumed |
|----------|-------------|---------------|
| Toke (access tokens) | 2,719,886 | 4,975 MB |
| File (file objects) | 6,644,575 | 2,534 MB |
| SeAt (security attributes) | 10,855,380 | 994 MB |

After reboot (0.07 h uptime):

| Pool tag | Live objects | Pool consumed |
|----------|-------------|---------------|
| Toke | 6,499 | 11.5 MB |
| File | 33,913 | 12.9 MB |
| SeAt | 34,111 | 3.5 MB |

3. A/B test: Cowork stack ON vs OFF

Protocol: Measured leak rate with tokrate.ps1 (60–90 s samples via NtQuerySystemInformation) under normal load, then shut down the entire Cowork stack (killed Claude Desktop processes, stopped CoworkVMService, ran wsl --shutdown, verified vmmem gone), waited 20 s for churn to settle, and re-measured.

| Metric | Cowork stack ON | Cowork stack OFF | Reduction |
|--------|----------------|-----------------|-----------|
| Toke rate | 2.08/s | 1.03/s | −50% |
| File rate | 11.38/s | 4.57/s | −60% |
| SeAt rate | 8.51/s | 4.87/s | −43% |

CLI sessions (3 active) were kept running throughout — they are not significant contributors.

4. Jank tracks pool size, not free RAM

Validated across 3 full reboot cycles:

• Cycle 1 (191 h): Paged pool 9.57 GB, 26 GB free RAM, drag terrible (cursor p99 76 ms). Rebooted → pool 0.60 GB → drag smooth.
• Cycle 2 (93 h): Paged pool 6.26 GB, 24 GB free RAM, drag terrible (window p99 48 ms). Jank returned within hours of crossing 5 GB at 74 h.
• Cycle 3: Same pattern reproduced.

The degradation mechanism is millions of live kernel objects making the object manager and security-reference-monitor traversals slow on every file open and handle check — including those performed by DWM during window composition.

5. Exhaustive elimination of other suspects

The following were individually stop-tested with no change in leak rate (~6.5 Toke/s baseline):

• Corsair services (iCUE, CC_Engine, LEDKeeper2, CorsairDeviceControlService)
• OneDrive
• Google Drive / googledrivefs31931.sys
• PowerToys
• Process-creation churn (measured at 0.3/s vs 6.5 tokens/s)
• MediaTek Bluetooth (MTKBTSVC) — was leaking handles separately but not pool

All registered minifilters are Microsoft-signed. Microsoft Defender (WdFilter) is untestable due to tamper protection and is the likely source of the residual ~1 Toke/s.

Impact

• Forces system reboots every 3–4 days (or ~6–7 days with Claude Desktop closed)
• System-wide UI degradation: 50–200 ms input stalls, janky window dragging, slow Alt+Tab
• Affects the entire Windows session, not just Claude — all applications become sluggish

Reproduction

1. Install Claude Desktop on Windows 11 (build 26200.x)
2. Use normally for 3–4 days (Cowork VM will be active for sandboxed operations)
3. Monitor paged pool via (Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory).PoolPagedBytes / 1GB
4. Observe pool climbing ~1.5 GB/day under moderate use
5. When pool exceeds ~5 GB, attempt to drag a window — note stalls and hitching
6. Only a reboot reclaims the leaked pool

Suggested Fix

The Cowork VM's minifilter stack (wcifs/bindflt) needs to release the security contexts and file objects it captures per file operation. This appears to be the same retention bug described in #55361.

Tooling

All measurement tools used in this investigation are available at:
C:\Users\milan\Claude\VengeanceSysAdmin\tools\

• tokrate.ps1 — pool tag leak rate measurement
• snapshot.ps1 — full system state capture
• pooltag.ps1 — poolmon equivalent via NtQuerySystemInformation