Anthropic's Cowork Quietly Boots a 1.8 GB VM on Every Claude Desktop Launch, and Users Are Noticing

Anthropic has spent the past year pushing Claude from a chat box toward an agent that can run code, manipulate files, and operate inside a sandboxed environment. The product wrapper for that ambition on the desktop is Cowork, a mode that hands Claude a real virtual machine to work in. The pitch is reasonable. The execution, according to a steadily growing GitHub issue, is leaking memory and goodwill on machines that never opted in.

The company and the bet

Anthropic builds Claude, and its commercial story leans heavily on agentic workflows. The Claude Code CLI and the Claude Desktop app are both vehicles for moving users past simple question-and-answer into something that resembles a coworker who can actually do the task. Cowork is the consumer-facing version of that bet: open the app, describe what you want, and a containerized environment executes it.

That architecture requires virtualization. On Windows it leans on the Hyper-V Host Compute Service through the VirtualMachinePlatform feature; on macOS it uses Apple's Virtualization framework. When it works, the user gets an isolated machine that can install packages and run shell commands without touching the host. The problem users are documenting is that the machine starts whether or not anyone asked for it.

The problem they are reporting

The issue, filed by a developer named davidellett, is unusually well investigated. The report walks through a Razer Blade laptop running Windows 11 Pro with 16 GB of RAM where the Claude Desktop app spawns a Vmmem process consuming roughly 1,800 MB at idle, 0% CPU, on every single launch. On a 16 GB system that is more than 11% of total memory consumed before the user types anything.

The diagnostic work rules out the usual suspects. WSL is not installed. Hyper-V management tools are not installed. Docker is absent. Windows Sandbox is disabled. The only virtualization feature enabled is VirtualMachinePlatform, and the vmcompute service, set to manual start, gets triggered at boot by an RPC interface event whose parent process is services.exe. In plain terms, the VM is not a user-initiated launch. It is a service trigger firing on its own.

The report also surfaces a housekeeping failure. The investigator found 2,689 stale session files sitting in %APPDATA%\Claude\local-agent-mode-sessions\, each named in the Docker-style adjective-plus-surname convention (nifty-dreamy-volta, tender-vigilant-goodall). None had been cleaned up. The Hyper-V Compute Admin log, meanwhile, throws a repeating error on every boot: Invalid JSON document '$', suggesting the VM is being asked to start from a malformed configuration and doing it anyway.

Deleting all 2,689 files and killing the VM processes did not solve it. Reopening the app immediately respawned both the VM and the 1.8 GB memory footprint.

Why this resonates

What turns a single bug report into something worth watching is the thread underneath it. The reproductions are not limited to one machine or one platform.

A macOS user on Claude 1.1.4498 reports an Apple VirtualMachine consuming 2.61 GB on startup with Cowork disabled on both personal and work accounts. A Windows 11 Home user confirms 1,854 MB of Vmmem. One commenter notes they never used Cowork once and was still forced to download a 2 GB rootfs.vhdx image, then watched it re-download every launch after they tried to block it. A user on a newer MSIX build, v1.1.9310.0, describes a more severe variant: roughly 25 GB of RAM and ten-plus claude.exe processes on launch before opening Cowork at all.

The community response has been to route around the product. One user disabled the CoworkVMService outright via a registry edit (Set-ItemProperty ... -Name "Start" -Value 4). Another, JesperLive, compiled the various fixes into a ClaudeFix toolkit on GitHub. Several simply uninstalled the desktop app and went back to the Claude Code CLI or the web version. The official workaround, disabling VirtualMachinePlatform entirely, kills the VM but also kills Cowork, which is the whole point of the feature.

GitHub's own automation labeled the issue invalid, noting it does not seem related to Claude Code, which is technically correct and practically beside the point for the users affected.

The pattern worth naming

Strip away the specifics and this is a familiar shape in the current AI build-out. Companies are racing to ship agent infrastructure, and that infrastructure is heavy. A sandboxed VM is the honest way to let an AI run arbitrary code without compromising the host, and Anthropic deserves some credit for not pretending agents can be safe without isolation. The trade-off is that isolation has a resource cost, and right now that cost is being paid by every user on launch rather than only the ones who reach for the feature.

The fixes the reporters are asking for are not exotic. Initialize the VM on demand when a Cowork or agent session actually starts. Clean up session files when sessions end. Fall back to chat-only mode gracefully when VM initialization fails or is unnecessary. These are the kinds of requirements that get deferred when a feature ships fast and the team is optimizing for capability over restraint.

There is a quieter business lesson here too. The users hitting this are not casual; they are the developers and power users who file detailed PowerShell diagnostics and read service triggers. They are precisely the audience an agent product needs to win, and several of them are downgrading to the web client or competing tools because a chat session should not cost two gigabytes of idle virtualization. Anthropic has not posted a resolution on the thread as of this writing, and related reports keep getting filed against newer builds, which suggests the on-demand initialization fix is still pending. For a company whose entire premise is that agents will quietly handle work in the background, an agent that loudly consumes memory in the background is an awkward first impression.