[BUG] Claude Desktop (Windows): cowork-vm transiently holds ~18 GB host RAM, not attributable to any process
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?
Related: #40249 (closed), #29045, #57247
Claude Desktop 2.37337.1, Windows x64, 48 GB RAM. No WSL distributions installed, no Hyper-V VMs.
A Claude Desktop chat was linked to this computer (Cowork / remote-devices). Only file staging/commit tools were used, no device shell commands. Host memory spiked for a few minutes, then dropped back without me closing anything:
| | During spike | A few minutes later |
|---|---|---|
| In use | 30.7 GB | 12.1 GB |
| Committed | 35.6 / 48.2 GB | 17.3 / 48.2 GB |
| Paged / non-paged pool | 505 / 371 MB | 507 / 372 MB |
| Compressed | 0 MB | 0 MB |
During the spike, all user-mode processes together held only ~12 GB private memory (Brave 4.2 GB, vmmem 4.0 GB, Claude 0.8 GB, rest small). Roughly 18–19 GB was not attributable to any process, and pool usage was unchanged. The only VM running was the Cowork VM (see logs).
Caveat: I did not capture the VM's own memory during the spike, so the attribution to cowork-vm is circumstantial — it is the only VM, and the unattributed memory was released on its own.
What Should Happen?
The Cowork VM should not be able to transiently claim ~18 GB of host RAM, or there should be a configurable memory cap (#57247).
Error Messages/Logs
`hcsdiag list` (admin) during the session — the only compute system:
cowork-vm-<id>
VM, Running, <guid>, cowork-vm-<id>
Earlier the same evening the machine became unresponsive and was restarted. System log just before the restart:
- 7038 Service Control Manager: The WerSvc service was unable to log on as NT AUTHORITY\SYSTEM with the currently configured password
- 7031 Service Control Manager: The Web Threat Defense Service service terminated unexpectedly
- 1074 User32: restart initiated via StartMenuExperienceHost (Other, Unplanned)
Other large consumers were running at that time too (llama-server ~17 GB, Brave ~15 GB), so the VM's share in that incident is not confirmed.Steps to Reproduce
Not deterministic.
- Open Claude Desktop on Windows and link a chat to the computer (Cowork / remote-devices).
- Use file tools (folder access, stage/commit files) over ~45 minutes.
- Watch Task Manager → Performance → Memory and per-process private bytes; compare total In use against the sum of process private memory.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Version prior to 2.37337.1 not recorded.
Claude Code Version
N/A — Claude Desktop app 2.37337.1 (Windows), not the Claude Code CLI
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Task Manager → Performance → Memory, during the spike:
In use (Compressed) 30.7 GB (0 MB)
Available 17.2 GB
Committed 35.6/48.2 GB
Cached 14.8 GB
Paged pool 505 MB
Non-paged pool 371 MB
A few minutes later, nothing closed:
In use (Compressed) 12.1 GB (0 MB)
Available 35.8 GB
Committed 17.3/48.2 GB
Cached 14.8 GB
Paged pool 507 MB
Non-paged pool 372 MB
Top processes by private memory during the spike (grouped by name):
brave 37 procs 4.21 GB private 6.06 GB WS
vmmem 1 proc 4.01 GB private 0.65 GB WS
claude 8 procs 0.77 GB private 1.33 GB WS
UGREEN NAS 7 procs 0.45 GB
NVIDIA App 5 procs 0.44 GB
(all others < 0.45 GB each)
Hardware: 48 GB DDR4 (4×DIMM). Cached stayed at 14.8 GB in both readings, so the drop is not cache being trimmed.