### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Claude Desktop with Cowork enabled driv

[BUG] Cowork on Windows 11 causes kernel non-paged pool leak on NtFC tag (NTFS FCB), accumulates ~2 GB/hour to system exhaustion

Resolved 💬 3 comments Opened May 1, 2026 by CallMarcus Closed May 5, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

<html>
<body>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Claude Desktop with Cowork enabled drives a sustained kernel non-paged pool leak on the Windows 11 host, accumulating on the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">NtFC</code> (NTFS File Control Block) pool tag. Under active workload the leak grows at roughly 2 GB/hour at peak, exhausting non-paged pool and pushing a 32 GB system to memory starvation within a working day. The leak survives reboot as a reproducible pattern. Per-process memory accounting does not explain the loss — top per-process non-paged usage stays at ~1.26 MB throughout. The damage is in kernel pool and persists until reboot.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">This is a kernel-side reference accumulation, distinct from previously reported user-mode performance issues (#22543, #26302).</p>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Environment</h2>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">OS: Windows 11, 32 GB RAM, Lenovo X1 Carbon</li>
<li class="whitespace-normal break-words pl-2">Claude Desktop: <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Claude_1.5354.0.0_x64__pzs8sxrjxfjjc</code> (MSIX install)</li>
<li class="whitespace-normal break-words pl-2">Cowork service: <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">CoworkVMService</code>, binary <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">C:\Program Files\WindowsApps\Claude_1.5354.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe</code></li>
<li class="whitespace-normal break-words pl-2">WSL2 active with frequent dev workloads (FastAPI, Python, Git over <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">/mnt/c/</code>)</li>
<li class="whitespace-normal break-words pl-2">Onset: temporally correlates with enabling Claude Cowork</li>
<li class="whitespace-normal break-words pl-2">All filesystem minifilters in the captured stack are first-party Microsoft components</li>
</ul>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Symptom</h2>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Non-paged pool grows from ~0.6 GB at fresh boot to >19 GB before commit pressure forces remediation</li>
<li class="whitespace-normal break-words pl-2"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Available MB</code> falls below 1 GB and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">CommitPercent</code> exceeds 95%</li>
<li class="whitespace-normal break-words pl-2">System becomes unresponsive</li>
<li class="whitespace-normal break-words pl-2">Damage persists in kernel pool until reboot</li>
<li class="whitespace-normal break-words pl-2">Per-process non-paged memory remains tiny throughout (top process ~1.26 MB)</li>
</ul>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Diagnostic Evidence</h2>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Pool tag attribution</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">PoolMon captures across five sessions (21–25 Apr 2026) consistently identify <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">NtFC</code> as the dominant growing tag during leak phases.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Representative checkpoints, single boot session 22 Apr 14:30:50 → 23 Apr 16:56:42:</p>
<div class="overflow-x-auto w-full px-2 mb-6">
Time | Non-paged pool | NtFC bytes | NtFC allocs | NtFC frees
-- | -- | -- | -- | --
22 Apr 14:42 | 2.18 GB | 1.49 GB | low | balanced
23 Apr 09:59 | 9.76 GB | 9.28 GB | growing | minimal
23 Apr 16:35 | 17.56 GB | 17.05 GB | 134,051,270 | 484
23 Apr 16:56 | 19.74 GB | 19.30 GB | continuing | continuing

</div>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">NtFC</code> accounts for >98% of measured non-paged growth across the captured window. The allocation-to-free ratio (134M : 484) indicates near-zero release, not a slow drift. <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Per Alloc</code> size of 144 bytes is consistent with NTFS FCB header allocations.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Reboot behaviour</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The leak resets per boot to ~0.6 GB baseline but reproduces under workload on every fresh boot:</p>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Boot at 21 Apr 19:12 → 11.3 GB by 21:18 (~2 hours)</li>
<li class="whitespace-normal break-words pl-2">Boot at 21 Apr 21:37 → 7.3 GB by next afternoon</li>
<li class="whitespace-normal break-words pl-2">Boot at 22 Apr 14:30 → 19.7 GB by 23 Apr 16:56 (peak)</li>
</ul>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Confirms the leak is not stale boot state but a reproducible runtime pattern.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Filter stack at time of leak</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">fltmc filters</code> captured during a leak session, all altitudes consistent with first-party Windows components:</p>
<div role="group" aria-label="Code" tabindex="0" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
isolate
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md backdrop-blur-md _fill_10ocf_9 _ghost_10ocf_96" type="button" aria-label="Copy to clipboard" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3A1.5 1.5 0 0 1 14 4.5V6h1.5A1.5 1.5 0 0 1 17 7.5v8a1.5 1.5 0 0 1-1.5 1.5h-8A1.5 1.5 0 0 1 6 15.5V14H4.5A1.5 1.5 0 0 1 3 12.5v-8A1.5 1.5 0 0 1 4.5 3zm1.5 9.5a1.5 1.5 0 0 1-1.5 1.5H7v1.5a.5.5 0 0 0 .5.5h8a.5.5 0 0 0 .5-.5v-8a.5.5 0 0 0-.5-.5H14zM4.5 4a.5.5 0 0 0-.5.5v8a.5.5 0 0 0 .5.5h8a.5.5 0 0 0 .5-.5v-8a.5.5 0 0 0-.5-.5z"></path></svg></div><div class="absolute inset-0 flex items-center justify-center"><div class="transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.188 5.11a.5.5 0 0 1 .752.626l-.056.084-7.5 9a.5.5 0 0 1-.738.033l-3.5-3.5-.064-.078a.501.501 0 0 1 .693-.693l.078.064 3.113 3.113 7.15-8.58z"></path></svg></div></div></div></button></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;"><span><span>bindflt altitude 409800
</span></span><span>FsDepends altitude 407000
</span><span>UCPD altitude 385250.5
</span><span>WdFilter altitude 328010
</span><span>storqosflt altitude 244000
</span><span>wcifs altitude 189900 (2 instances on C:)
</span><span>CldFlt altitude 180451
</span><span>bfs altitude 150000
</span><span>luafv altitude 135000
</span><span>UnionFS altitude 130850 (loaded, 0 instances)
</span><span>npsvctrig altitude 46000
</span><span>Wof altitude 40700
</span><span>FileInfo altitude 40500</span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">wcifs</code> (Windows Container Isolation Filter) and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">UnionFS</code> are container-isolation filters not present in earlier baseline captures from before Cowork was enabled on this machine. These filters appear to have been activated by Cowork's installation or the Windows feature dependencies it pulled in.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Per-process attribution</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Process snapshots taken at peak non-paged usage (17.5 GB) show:</p>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Top per-process non-paged: <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">winlogon</code> at 1.26 MB</li>
<li class="whitespace-normal break-words pl-2"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">vmmemWSL</code> working set: 1.7 GB (private, not non-paged)</li>
<li class="whitespace-normal break-words pl-2"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">claude.exe</code> working set: ~280 MB</li>
<li class="whitespace-normal break-words pl-2">No process-attributable explanation for the kernel pool growth</li>
</ul>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">This rules out user-mode memory leaks and points to a kernel-side reference accumulation in NTFS FCB allocations.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Uninstall behaviour</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Uninstalling Claude Desktop and removing the Cowork VHDX from <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">%LOCALAPPDATA%</code>:</p>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Removed <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">FsDepends</code> filter (consistent with no VHDX being mounted)</li>
<li class="whitespace-normal break-words pl-2">Did <em>not</em> remove <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">wcifs</code> or <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">UnionFS</code> (these remain registered with Windows)</li>
<li class="whitespace-normal break-words pl-2">Did not register or remove any Cowork-specific kernel driver</li>
</ul>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">This suggests Cowork uses Windows-provided container infrastructure (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">wcifs</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">bindflt</code>) rather than shipping its own filesystem driver, but its operations through that infrastructure appear to leak FCB references.</p>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Reproduction</h2>
<ol class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Fresh-boot Windows 11 host with Cowork installed and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">CoworkVMService</code> running</li>
<li class="whitespace-normal break-words pl-2">Begin a typical dev workload involving WSL2 file watchers, Git operations on <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">/mnt/c/</code>, container-aware tooling, or anything that exercises the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">wcifs</code>/<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">bindflt</code> paths</li>
<li class="whitespace-normal break-words pl-2">Sample non-paged pool with <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Get-Counter '\Memory\Pool Nonpaged Bytes'</code> or PoolMon at 60 second intervals, with the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">/iFile</code> filter to focus on filesystem tags</li>
<li class="whitespace-normal break-words pl-2">Observe <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">NtFC</code> allocations climbing without matching frees, accumulating in non-paged pool</li>
</ol>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The leak rate varies with workload intensity (peak ~2 GB/hour) but reproduces every session.</p>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Suspected mechanism</h2>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">NTFS allocates FCB structures on the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">NtFC</code> tag for file metadata. Some operation — most plausibly a code path through <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">wcifs</code> or <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">bindflt</code> exercised by Cowork's VM file projection — causes FCB references to be retained rather than released. The minifilter chain holds the reference, NTFS cannot free the FCB, and the pool grows monotonically until reboot.</p>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Workarounds tried</h2>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Daily <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">wsl --shutdown</code>: helps but does not fully reset FCB state</li>
<li class="whitespace-normal break-words pl-2"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">vmIdleTimeout=60000</code> in <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">.wslconfig</code>: reduces growth in idle periods</li>
<li class="whitespace-normal break-words pl-2">Periodic reboot: works but disruptive</li>
<li class="whitespace-normal break-words pl-2">Migrating repos from <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">/mnt/c/</code> to ext4 inside WSL: not yet tested in isolation</li></ul>
</body>
</html>

What Should Happen?

Confirmation of whether Cowork's file operations through wcifs/bindflt are known to retain FCB references
Guidance on whether disabling specific Cowork features (e.g. project file sync) reduces the leak rate
A way to run Claude Desktop without Cowork's VM infrastructure activating, for users who don't use the feature
Improved uninstall that removes the VHDX and unregisters container filters when Cowork was their only consumer

Error Messages/Logs

Captured artefacts available on request

summary.csv time-series across five sessions showing pool/commit/available metrics
Full PoolMon outputs at multiple checkpoints
fltmc filters and fltmc instances before and after Cowork uninstall
driverquery /v /fo csv before and after Cowork uninstall
Process snapshots correlating user-mode memory with pool growth
Hunt notes documenting the diagnostic process

Happy to share these via whatever channel works best.

Steps to Reproduce

Fresh-boot Windows 11 host with Cowork installed and CoworkVMService running
Begin a typical dev workload involving WSL2 file watchers, Git operations on /mnt/c/, container-aware tooling, or anything that exercises the wcifs/bindflt paths
Sample non-paged pool with Get-Counter '\Memory\Pool Nonpaged Bytes' or PoolMon at 60 second intervals, with the /iFile filter to focus on filesystem tags
Observe NtFC allocations climbing without matching frees, accumulating in non-paged pool
The leak rate varies with workload intensity (peak ~2 GB/hour) but reproduces every session.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.123

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗