[BUG] Claude Desktop spawns 1.8 GB Hyper-V VM on every launch, even for chat-only use

Open 💬 28 comments Opened Feb 26, 2026 by davidellett

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?

[BUG] Claude Desktop spawns 1.8 GB Hyper-V VM on every launch, even for chat-only use
Environment

Note: This issue is specific to the Claude Desktop app (Windows), not Claude Code CLI.

OS: Windows 11 Pro 25H2, Build 26200.7840
Hardware: Razer Blade 15 Base Model (Late 2020), i7-10750H, 16 GB RAM
Claude Desktop: Latest version as of 2/26/2026
Windows Features: VirtualMachinePlatform enabled; Hyper-V, WSL, Docker, and Windows Sandbox are all disabled
Core Isolation / Memory Integrity: Off

Summary
The Claude Desktop app launches a Hyper-V virtual machine (Vmmem) consuming approximately 1.8 GB of RAM every time it starts — even when the user only needs chat functionality and has no intention of using Cowork or agent mode. On a 16 GB laptop, this represents over 11% of total memory consumed by infrastructure that isn't being used.
Steps to Reproduce

Install Claude Desktop on Windows 11 with VirtualMachinePlatform enabled
Use Cowork/agent mode at least once (this creates session files)
Close and reopen Claude Desktop — or simply reboot the machine
Open Task Manager and observe Vmmem consuming ~1,800 MB

What Happens
On every launch, the Claude Desktop app triggers the Hyper-V Host Compute Service (vmcompute) via an RPC interface event, which spawns a vmwp.exe process hosting a full virtual machine. This VM appears as "Vmmem" in Task Manager at approximately 1,796–1,846 MB.
The Hyper-V Compute Admin event log shows repeated errors:
"The specified property query is invalid: The virtual machine or container JSON document is invalid. (0xC037010D, 'Invalid JSON document '$'')"
These errors have been occurring since at least 2/19/2026, triggered on every boot and app launch.
Root Cause Investigation
Through extensive PowerShell diagnostics, we confirmed:

WSL is not installed — wsl --shutdown returns "not installed"
Hyper-V management tools are not installed — Get-VM fails
Docker is not installed — no Docker processes found
Windows Sandbox is disabled
Core Isolation / Memory Integrity is off (and was off before this issue started)
VirtualizationBasedSecurityStatus shows 2 (running), likely due to LSA Protection being enabled — but this alone doesn't explain the 1.8 GB VM
The only enabled virtualization feature is VirtualMachinePlatform

The vmcompute service is set to Manual start but is triggered at boot by an RPC interface event (GUID: bc90d167-9470-4139-a9ba-be0bbbf5b74d). The parent process is services.exe (PID 1400), confirming it's a service trigger, not a user-initiated launch.
We found 2,689 stale session files in %APPDATA%\Claude\local-agent-mode-sessions\ — all from previous Cowork sessions that were never cleaned up. Session names follow Docker-style naming (e.g., "nifty-dreamy-volta", "tender-vigilant-goodall", "admiring-elegant-johnson"). Even after deleting all 2,689 files and killing vmcompute/vmwp, simply reopening the Claude Desktop app immediately respawned the VM and the 1.8 GB Vmmem process.
Impact
On a 16 GB system, this bug causes memory usage to jump from ~50% to ~62% at idle before the user does anything. Combined with normal application load, this pushes total usage to 70–75%, causing system sluggishness and forcing the user to manually kill VM processes after every launch.
Expected Behavior

The Claude Desktop app should not spawn a VM for chat-only sessions
If Cowork infrastructure is needed, it should initialize on demand — only when the user actually starts a Cowork/agent session
Stale session files from previous Cowork sessions should be cleaned up automatically, not accumulate indefinitely (2,689 files in our case)
The app should fall back to chat-only mode if VM initialization fails or is unnecessary, rather than unconditionally starting VM infrastructure

Current Workaround
The only reliable workaround is to disable VirtualMachinePlatform entirely:
powershellDisable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart
This prevents the VM from launching but also disables Cowork functionality. Alternatively, the user can kill the VM processes after every launch:
powershellStop-Process -Name vmwp -Force
Stop-Process -Name vmcompute -Force
Chat functionality continues to work normally after killing these processes.
Request
Please modify the Claude Desktop app so that:

VM/container infrastructure only initializes when Cowork or agent mode is actively requested
Old session data is cleaned up automatically after sessions end
The app gracefully handles the absence of VM infrastructure without degraded chat performance

What Should Happen?

The Claude Desktop app should not spawn a Hyper-V VM (Vmmem, ~1.8 GB RAM) when launching for chat-only use. VM/container infrastructure should only initialize when the user actively starts a Cowork or agent session. Stale session files should be cleaned up automatically after sessions end.

Error Messages/Logs

Hyper-V Compute Admin log shows repeated errors on every boot:
"The specified property query is invalid: The virtual machine or container JSON document is invalid. (0xC037010D, 'Invalid JSON document '$'')"

Steps to Reproduce

  1. Install Claude Desktop on Windows 11 with VirtualMachinePlatform enabled
  2. Use Cowork at least once
  3. Close and reopen Claude Desktop (or reboot)
  4. Observe Vmmem in Task Manager consuming ~1,800 MB at 0% CPU

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop (Windows) latest as of 2/26/2026

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

See detailed bug report in description above.

<img width="1143" height="1415" alt="Image" src="https://github.com/user-attachments/assets/3d345f14-abce-442e-9ef2-538fcd749200" />

View original on GitHub ↗

28 Comments

Kylemitchell64 · 4 months ago

I'm having the exact same issues. As amazing as it is I had to uninstall it for now.

THEMaeker · 4 months ago

I too see the usage identical to others in this thread. It’s worth mentioning that disabling the auto login feature allows you to restart to reclaim the Mem back as Claude Coworker only calls the vmmem upon launch. Until Anthropic can deploy a fix this has saved precious (and expensive) memory when needed for other tasks

stevenodb · 4 months ago

Same issue here on the macOS version:
Claude 1.1.4498 (24f768) 2026-02-26T19:47:09.000Z

Claude boots an Apple VirtualMachine on startup using about 2,61 GB of memory. Personal account and Work account (with Cowork disabled)

8rmartin-sketch · 4 months ago

same issue.
Windows 11 Home25H2
Claude 1.1.4498 (24f768) 2026-02-26T19:47:09.000Z
1854 MB Vmmem

Ti-flo · 4 months ago

Same issue here.

And i didn't even used Cowork once.

What really upset me is that you're forced to download 2go of rootfs.vhdx even if you don't need it.
I blocked Claude from transferring the 2 rootfs files from temp to their permanent folder so now it never lauches vmmem, but now each time i launch Claude it downloads 2go again..

Still working on it !

If you have any advices, i'll be glad to hear them :)

Ti-flo · 4 months ago

I gave up on blocking the download because you need to block bc.googleusercontent.com IPs and Claude won't connect without it apparently..

I removed the locks i put before for the rootfs to properly install in AppData/Roaming/Claude and i deactivated only the CoworkVMService (the display name is Claude) with this command in PowerShell :
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name "Start" -Value 4

Now i got this uselss 2go files but vmmem doesn't launches and i use the chat normally

EDIT : of course i'm doing this because i don't use cowork, if you are, don't do this ^^

JesperLive · 4 months ago

Hi! Just throwing it out here, compiled a variety of community issues and fixes / prevention techniques in to 1 "toolkit", can be found here https://github.com/JesperLive/ClaudeFix - I hope it might be useful

phillipdebruin · 4 months ago

Same issue for me. It is actually preventing me from using Claude to a large extent.

hunglng · 4 months ago

I need to switch to web version because of this isse. I need option that allow me to disable claude code and cowork

nCino-ztuman · 4 months ago

Same issue. Claude desktop needs to clearly describe the OS and hardware requirements for its desktop app. I understand claude code and cowork use a VM to perform tasks, but why does it init at startup? What is the high ram usage for while idle? Why not use a lighter weight virtualization platform?

Floorback · 3 months ago

Same here, I uninstalled app for now, using cc cli, hope it will be fixed soon.

sjmotew · 3 months ago

Experiencing a significantly more severe variant of this on v1.1.9310.0
(MSIX, Windows 11 Pro, 32GB RAM). Claude Desktop consumes ~25GB RAM
immediately on launch with 10+ claude.exe processes — before opening
Cowork. Closing the app drops to near zero. Filed as new issue #[your
new issue number] with full details.

OptimusPi · 3 months ago

This is probably what's causing the crash since ~3 months ago (Sorry, I stopped subscribing.)

Well I came back, and it's definitely not working, can't use remote or co work, haven't had time to mess around with it. Thanks for making this GitHub issue

Windows 11 Insiders Pro x64
64GB memory ddrr5
ryzen 9800x3D
nvidia rtx 4070 super 12GB

mikescott · 3 months ago

This has just started happening for me in macOS even though I've been using Claude for months. I understand this VM is for the Cowork feature but I don't use it.

Claude is already a terrible Electron app that will happily eat 3GB+ of RAM, I don't need it using another ~3GB for a VM that is performing no function for me, and which the Claude UI gives me absolutely no control over. When I kill the VM it just respawns.

liflovs · 3 months ago

same, we need an option to turn this off, is there one?

freesoft · 2 months ago

2025 MacBook Air M4 (MacOS 26.3.1 (25D2128)) , 24GB. Launched Claude Desktop (had used Cowork before, Claude 1.3109.0 (35cbf6) 2026-04-16T20:32:01.000Z), didn't touch the Cowork tab. Virtual Machine Service for Claude showed up at 1.89GB, with total Claude Desktop processes around 3.2GB. Cmd+Q frees it all; relaunching auto-loads the VM again within a minute.

+1 for on-demand VM initialization.

juliandevelops · 2 months ago

Same issue here on M4 MacBook Pro. Claude Desktop spawns a process for virtual machines using >3GB of RAM, even with Cowork inactive. Haven't used it once.

chid · 1 month ago

still an issue, it restarts automatically after forcibly killing it - perhaps that's the simplest fix, have it so that it needs to be manually restarted (so users can just kill it directly)

TonyRice · 1 month ago

This is still relevant. Installed Claude desktop for the first time on windows and my SSD started going crazy while creating the VM. This isn't something that should be happening without making it clear it's part of the system. Ideally being able to disable it would be great.

lokitoth · 1 month ago

This may have something to do with WSL: Is your Claude Desktop working against a WSL repo or in WSL? (Or trying to run in Docker if Docker is configured to use WSL?)

jasimmk · 1 month ago

I saw this when Cowork was released. In the early days, it used to boot up whenever you queried something in Cowork, and the initialization time was much higher.

Cowork was using a VM to securely perform operations on the relevant folder without affecting the original OS. They started booting it in advance, assuming everyone would be using Cowork, and this helped reduce the startup delay.

andrewssobral · 1 month ago

Same here:

MacBook Pro

13-Inch, M1, 2020

Chip: Apple M1
Memory: 16 GB
Startup disk: HD
Serial number: FVFF42G2Q05P
macOS: Tahoe 26.3

The VM should be optional , this is why i usually go to claude code cli and/or claude web for most of my work. Moreover, the vm_bundles takes 6Gb of disk space for "nothing" (i rarely use cowork).

<img width="724" height="220" alt="Image" src="https://github.com/user-attachments/assets/2f22052d-714d-403b-8f14-e90288f294a8" />

gtirloni · 1 month ago

Developer > Open App Config File:

{
  "preferences": {
    "secureVmFeaturesEnabled": false
  }
}
ejpir · 1 month ago

In chat mode, you can also suffer from prompt injections, so this seems like it is needed there too?

abjbhat · 1 month ago

I have a 16 GB Macbook Air M4 Base model with just 256 GB of storage. I can definitely recall that older versions of Claude Desktop did not make use of a VM. I don't need this for the chat functionality. I would very much like an option to turn this off.

wedontdozero · 1 month ago

Are we never going to see a fix because github actions labeled this as invalid?

sunctrx · 1 month ago

Feature request: A per-device toggle to disable or opt out of Cowork, either as a setting within Claude Desktop or as a lightweight install option that excludes it.
Some machines don't need Cowork at all. Running Claude Desktop on an older PC (Intel Core i5-9500) for chat-only use, the background VM still launches on every startup and creates unnecessary memory and CPU pressure on lower-spec hardware where Cowork was never intended to be used.

Sushyiii · 25 days ago

It consistently takes up about 1.6GB of ram on macOS with the process name Virtual Machine Service for Claude. On lower-spec Macs (e.g. 8GB models), this is a significant share of available memory and noticeably degrades overall system performance during dev workflows. Claude Desktop app version: Claude 1.14271.0 (c8f4d8)