`[BUG] Claude Desktop MSIX v1.1.9310.0 consumes 25GB RAM on launch (Windows 11, 32GB) — Cowork VM + stale session accumulation`

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?

Environment

• OS: Windows 11 Pro
• Hardware: ASUS workstation, RTX 3090, 32GB RAM
• Claude Desktop: v1.1.9310.0 (MSIX/Store install, package: Claude_1.1.9310.0_x64__pzs8sxrjxfjjc)
• MCP servers: 3 custom (Proxmox, Technetium DNS, Filesystem) — all

connect successfully per mcp.log

• NordVPN installed (virtual network adapters present)
• Hyper-V: Enabled, vmcompute/vmms: Running

Summary

Claude Desktop consumes approximately 25GB of 32GB RAM immediately on
launch, spawning 10+ claude.exe processes, before any Cowork tab is
opened or any session is initiated. This renders the machine unusable
for other work and prevents Cowork from launching (insufficient RAM for
Hyper-V VM allocation).

Steps to Reproduce

1. Launch Claude Desktop v1.1.9310.0 (MSIX) on Windows 11 Pro, 32GB RAM
2. Open Task Manager — do NOT click Cowork tab
3. Observe 10+ claude.exe processes within seconds of launch
4. Observe ~25GB RAM consumed (85%+ of 32GB total)
5. Exit Claude Desktop via system tray → Exit
6. Observe RAM drops to near zero immediately

Expected Behavior

2-3 claude.exe processes, <2GB RAM at idle (chat-only launch)

Actual Behavior

10+ processes, ~25GB RAM consumed on every launch before any user action

Key Observations

• RAM spike is immediate — occurs before opening Cowork tab
• MCP servers are NOT the cause — all 3 connect cleanly with no

crash-loops per mcp.log

• No errors in main.log — startup sequence completes normally
• CoworkVMService is present (Stopped) but Claude cannot start it

programmatically — manually running Start-Service CoworkVMService
succeeds, but Claude still fails to use it

• The 25GB consumption appears to be in the Electron/WebView2 layer,

not the Hyper-V VM (Vmmem process is separate)

Log Evidence

main.log shows clean startup — no errors, no crash loops:

[SkillsPlugin] Found 5 enabled skills
[MCP Server] proxmox — connected successfully  
[MCP Server] technetium-dns — connected successfully
[MCP Server] filesystem — connected successfully

cowork_vm_node.log shows repeated startup failures after service
won't start:

[VM:start] Startup failed: Error: VM service not running. 
The service failed to start.
[VM:start] Skipping auto-reinstall (already attempted once)

Cowork Failure Cascade (secondary issue, caused by RAM exhaustion)

When RAM is available (after killing other processes), Cowork fails
with this sequence:

1. VHDX file not found at MSIX path — actual files are at

%APPDATA%\Claude\vm_bundles\ (path mismatch)

1. After junction symlink fix: VM service not running —

CoworkVMService won't start via app but starts via PowerShell

1. After manual service start: HCS 0x800705AF — paging file error

(paging file is 98GB; real cause is insufficient free RAM due to
item 1 above)

Related Issues

• #29045 — VM spawns on every launch (1.8GB variant; this is ~14x worse)
• #32304 — 21GB RAM during workflow with sub-agents
• #26302 — Performance regression since v1.1.3189
• #27801 — VM service not running persists after reboot
• #25914 — VHDX NTFS path mismatch

Workaround

None viable. For chat-only use, killing vmwp/vmcompute per #29045
does not resolve the 25GB consumption in this case — the memory is
in claude.exe processes, not Vmmem.

Ask

1. Investigate why v1.1.9310.0 spawns 10+ processes consuming 25GB

at launch on Windows — this appears to be a regression beyond the
VM-on-launch issue in #29045

1. Fix CoworkVMService so the app can start it (currently requires

manual PowerShell invocation)

1. Fix VHDX path mismatch between MSIX virtualized path and

%APPDATA%\Claude\vm_bundles\

What Should Happen?

What Should Happen

1. Claude Desktop should launch with <2GB RAM and 2-3 processes for

chat-only use. VM/Cowork infrastructure should initialize lazily —
only when the user explicitly opens the Cowork tab and starts a
session, not on every app launch.

1. CoworkVMService should be startable by the app itself. The service

registers successfully and starts via Start-Service CoworkVMService
in PowerShell, but Claude Desktop cannot start it programmatically.
The app should be able to manage its own registered service.

1. VHDX files should be found at a consistent path. The app downloads

bundle files to %APPDATA%\Claude\vm_bundles\ but CoworkVMService
looks for them at the MSIX virtualized path
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\.
These should be the same location, or the app should resolve both.

1. Stale session files should be cleaned up automatically. Failed

Cowork attempts accumulate files in
%APPDATA%\Claude\local-agent-mode-sessions\ indefinitely,
compounding memory pressure on every subsequent launch.

1. HCS errors should surface actionable messages. The

0x800705AF paging file error is misleading — the real constraint
is insufficient free RAM caused by the eager VM launch in item 1.
Error messages should reflect actual root cause.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

1. Launch Claude Desktop v1.1.9310.0 (MSIX) on Windows 11 Pro, 32GB RAM
2. Open Task Manager — do NOT click Cowork tab
3. Observe 10+ claude.exe processes within seconds of launch
4. Observe ~25GB RAM consumed (85%+ of 32GB total)
5. Exit Claude Desktop via system tray → Exit
6. Observe RAM drops to near zero immediately

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is Claude Desktop v1.1.9310.0 (MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_