Claude Code's Cowork feature silently creates a 10GB VM on macOS, and CPU usage jumps to 55% even after deletion

Claude Code’s Cowork feature has been generating serious performance complaints on GitHub since February 2026. Users reported high CPU usage while idle and massive disk consumption every time Claude restarted. More than 35 reports piled up, and GitHub issue #22543 collected 81 thumbs up.

The VM bundle

The core of the problem is a claudevm.bundle that Claude automatically creates under ~/Library/Application Support/Claude/vm_bundles/.

~/Library/Application Support/Claude/vm_bundles/
└── claudevm.bundle/
    └── rootfs.img  # raw disk image larger than 10GB

This VM bundle exists for Cowork, the sandbox where Claude runs code on the user’s machine. The problem is that it gets created even when Cowork is not being used, and it gets recreated the next day even after deletion. One user reported 10GB of disk usage even though they had never enabled Cowork.

Reported sizes vary. The minimum is around 10GB, and one case reached 21.47GB. The compressed rootfs.img.zst can also remain after extraction, so the real disk usage is even larger than the displayed number.

VM architecture

The Cowork VM uses Apple’s Virtualization framework to run a lightweight Linux guest on macOS.

Item	Value
Virtualization layer	VZVirtualMachine (Apple Virtualization.framework)
Boot method	EFI / GRUB
CPU allocation	4 cores
Memory allocation	4GB
Network	VZVmnetNetworkDeviceAttachment shared mode
Host-guest communication	vsock

What is vsock?

vsock, or Virtio Socket, lets the host and guest talk directly through the hypervisor. It does not use the normal TCP/IP stack, so you do not need IP configuration or port forwarding, and the overhead is low. When the VM starts, guest_vsock_connect establishes the host connection, and all later command execution and file access go through that path.

Why a VM instead of a container?

Anthropic engineer Felix Rieseberg explained three reasons on Hacker News:

provide a fully isolated execution environment for Claude
get a stronger security boundary than a container
reduce “approval fatigue” for non-technical users

Containers share the host kernel, so a kernel exploit can reach the host. A VM separates the kernel too, which structurally reduces the risk that AI-generated code touches the host filesystem or network directly. The cost is the 10GB-plus disk hit, which is the real problem here.

CPU and memory impact

With the VM present, Claude Desktop resource usage looks like this:

State	CPU usage
Right after restart (idle)	~24%
After a few minutes	~55%
Right after deleting the VM	returns to normal
A few minutes after deletion	starts rising again

The 55% breakdown was roughly renderer 24%, main 21%, GPU 7%. In Activity Monitor, the Claude process group keeps running at that level even while idle.

Memory usage also shows swap growth, with swapins rising above 20,000 to 24,000. On an 8GB machine the system becomes noticeably sluggish.

The delete-and-regenerate loop

A temporary workaround is to delete the VM bundle and caches:

rm -rf ~/Library/Application\ Support/Claude/vm_bundles
rm -rf ~/Library/Application\ Support/Claude/Cache
rm -rf ~/Library/Application\ Support/Claude/Code\ Cache

That can drop disk usage from 11GB to 639MB and immediately reduce CPU load by about 75%. But after a few minutes or hours the VM comes back, and performance falls again. There is no reliable way to stop the regeneration loop yet.

One user reported that manual deletion only allowed the bundle to grow back to 13GB. Some people have already removed Claude Desktop and switched to the CLI only.

Issue #22543 links several symptoms that appear to share the same root cause:

#22715: VM heartbeat failure, SIGKILL
#23334: full Electron app crash from memory exhaustion
#25012: freeze during a Cowork session
#26258: 12GB bundle generation on Windows
#26646: 12GB bundle generation and API 500 errors on macOS 26.3

This is not limited to macOS; Windows has also been confirmed to generate 12GB bundles. The likely causes are missing cleanup after Cowork finishes and memory leaks in the background VM process.

vsock connection failures on macOS 26.x

Separate from the bundle-size problem, macOS 26.2 and later also have reports of the VM failing to start at all, including issue #23830.

The symptom is that boot succeeds, but guest_vsock_connect hangs for 60 seconds and then the startup loop retries.

[VM:steps] guest_vsock_connect started
[VM:start] Connection timeout, last completed step: vm_boot
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

Each retry can also leave the VM not fully stopped, with the vmnet gateway IP incrementing from 67.1 to 68.1 to 69.1. That looks like a resource leak where new VMs are spawned without releasing the old network resources.

graph TD
    A[VM starts] --> B[vm_boot succeeds]
    B --> C[guest_vsock_connect starts]
    C --> D{60 seconds pass}
    D -->|timeout| E[Try to stop the previous VM]
    E --> F[Stop fails]
    F --> G[vmnet resources not released]
    G --> H[Gateway IP increments]
    H --> A

The likely cause is a change in vsock socket initialization in macOS 26.x’s Virtualization framework. Once the bundle state gets corrupted, it does not self-heal.

Rebuilding the bundle

The community workaround is to back up only the session data, delete the VM bundle, and let Claude download it again.

# 1. Quit Claude completely
osascript -e 'quit app "Claude"'

# 2. Back up session data
mkdir -p ~/Documents/claude-vm-backup
cp ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/sessiondata.img \
   ~/Documents/claude-vm-backup/
cp ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/macAddress \
   ~/Documents/claude-vm-backup/
cp ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/machineIdentifier \
   ~/Documents/claude-vm-backup/

# 3. Delete the VM bundle and restart (a ~10GB re-download will start)
rm -rf ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle
open -a Claude

# 4. Restore the session data after setup completes
osascript -e 'quit app "Claude"'
cp ~/Documents/claude-vm-backup/sessiondata.img \
   ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/
cp ~/Documents/claude-vm-backup/macAddress \
   ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/
cp ~/Documents/claude-vm-backup/machineIdentifier \
   ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/
open -a Claude

Restoring sessiondata.img, macAddress, and machineIdentifier preserves Cowork session history, tasks, and installed packages. The downside is still the 10GB re-download.

Debug logs

The following logs are useful for debugging:

File	Contents
`~/Library/Logs/Claude/cowork_vm_node.log`	VM startup steps
`~/Library/Logs/Claude/cowork_vm_swift.log`	Virtualization.framework logs
`~/Library/Logs/Claude/coworkd.log`	General Cowork daemon logs

Anthropic’s response

GitHub issue #22543 was first reported on February 13, 2026 and was still open on March 3. An assignee was added and the bug, high-priority, oncall, and performance labels are on it, but Anthropic has not yet published an official comment or a fix timeline.

The discussion also spread on Hacker News, where Felix Rieseberg said the VM design choice is a real trade-off and that improvements are being considered. No concrete fix date has been announced.

Community suggestions

The main ideas raised in GitHub and Hacker News were:

Suggestion	Description
Lazy VM startup	only boot the VM when the Cowork tab is opened
Incremental updates	patch the 12GB bundle instead of re-downloading all of it
External disk storage	let users choose where the VM bundle lives
Lighter sandbox	replace the VM with OS-level sandboxing such as Apple Seatbelt
Opt-in only	do not generate a VM at all for users who never use Cowork

Lazy startup and opt-in only are the highest-value changes. For users who never use Cowork, the disk and CPU cost is pure waste.

If you daily-drive Claude Desktop and notice strange disk or CPU usage, check the size of ~/Library/Application Support/Claude/vm_bundles/ first. If you only want the CLI, switching to the npm-based claude command avoids the VM problem entirely.