Anthropic Claude Desktop consumes 1.8 GB RAM on Windows via Hyper-V bug
A reported issue in the Windows version of Anthropic’s application causes unnecessary memory overhead on systems with 16 GB of RAM, forcing users to manually intervene or disable virtualisation features.
A bug report lodged on GitHub has identified a significant resource leak in the Windows version of Anthropic’s Claude Desktop application. Users report that the software spawns a Hyper-V virtual machine consuming approximately 1.8 GB of RAM every time the application is launched, regardless of whether the user intends to utilise the standard chat interface or the more resource-intensive Cowork agent mode.
The issue, detailed in GitHub issue #29045, affects Windows 11 Pro systems, particularly those equipped with 16 GB of memory. On such devices, the unneeded virtual machine infrastructure causes idle memory usage to jump from approximately 50 per cent to 62 per cent before any user interaction occurs. This overhead frequently pushes total system memory consumption to between 70 and 75 per cent, resulting in noticeable system sluggishness for affected users.
Investigation into the root cause reveals that stale session files from previous Cowork sessions are triggering the Hyper-V Host Compute Service via a remote procedure call interface event. The reporter identified 2,689 orphaned session files in the local agent mode directory, which persist even after deletion and cause the virtual machine to respawn immediately upon reopening the application. These errors have been logged in the Hyper-V Compute Admin event log since at least 19 February 2026, citing invalid JSON documents within the virtual machine configuration.
The problem persists even when other virtualisation platforms such as Windows Subsystem for Linux, Docker, and Windows Sandbox are disabled. The only enabled feature is VirtualMachinePlatform, which allows the Hyper-V Host Compute Service to run. The application appears to unconditionally initialise this infrastructure upon launch rather than on demand, leading to the accumulation of memory-hungry processes identified as Vmmem in the Task Manager.
Current workarounds for users include manually terminating the vmwp and vmcompute processes after every launch, or disabling the VirtualMachinePlatform feature entirely via PowerShell. However, the latter approach prevents the use of Cowork functionality, highlighting a disconnect between the application’s default behaviour and the needs of users who only require basic chat capabilities.
