claude cowork: VM process spins CPU indefinitely on macOS 26.3 (Apple M5)

Status Fixed / completed

Reported on v2.1.44

Maintainer reply None cached

Activity 5 comments · opened Feb 16, 2026 · closed Feb 19, 2026

Description

claude cowork fails to start. The underlying com.apple.Virtualization.VirtualMachine process spawns but never reaches a usable state. Instead, it enters a CPU spin loop consuming ~316% CPU (4 vCPU threads) and 1.9GB RAM indefinitely.

Environment

Claude Code version: 2.1.44
macOS: 26.3 (Build 25D125)
Hardware: Apple M5, 32GB RAM
Virtualization framework: Version 1.0 (259.4.2)

Observed Behavior

Run claude cowork
The com.apple.Virtualization.VirtualMachine XPC service spawns with 4 vCPU threads, 10 disk I/O threads, 2 virtual clock threads
vCPU threads enter a tight Hv::Vcpu::run() → hv_trap loop (hypervisor trap handling + GIC interrupt state sync)
Process consumes ~316% CPU continuously and never completes startup
No crash reports generated — the VM doesn't crash, it just spin-loops

Process Sample (key threads)

The 4 vCPU threads (com.apple.virtualization.thread.cpu-0 through cpu-3) show:

~90% of samples in Hv::Vcpu::run_once() → hv_trap (hypervisor exit handling)
Remaining samples in GIC interrupt state synchronization (sync_from_gic_state, compute_list_registers)
Lock contention visible on os_unfair_lock in GIC list register computation
No threads appear idle or in a healthy wait state

All disk I/O threads and the defrag thread are waiting on condition variables (idle), suggesting the VM guest OS never gets far enough to perform disk I/O.

System State

System load average during reproduction: 31+ (system under heavy CPU pressure from the VM)
No related crash reports in ~/Library/Logs/DiagnosticReports/

Expected Behavior

claude cowork should either start successfully or fail gracefully with an error message instead of consuming all available CPU cores indefinitely.

Workaround

Kill the runaway process:

killall "com.apple.Virtualization.VirtualMachine"

View original on GitHub ↗

5 Comments

solomon23 · 8 months ago

Root Cause Found

The coworkd log reveals the actual cause — a Linux kernel panic inside the VM guest:

[   40.838054] Kernel panic - not syncing: corrupted stack end detected inside scheduler
[   40.838353] CPU: 2 PID: 237 Comm: jbd2/nvme0n1p1- Not tainted 6.8.0-94-generic #96~22.04.1-Ubuntu
[   40.838473] Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2094.80.5.0.0 01/16/2026
[   40.838596] Call trace:
[   40.838650]  dump_backtrace+0xa8/0x158
[   40.838807]  show_stack+0x24/0x50
[   40.838878]  dump_stack_lvl+0x3c/0x140
[   40.838974]  dump_stack+0x1c/0x38
[   40.839037]  panic+0x3ac/0x448
[   40.839109]  schedule_debug.constprop.0+0x19c/0x1c0
[   40.839197]  __schedule+0x8c/0x790
[   40.839266]  schedule+0x40/0x168
[   40.839336]  io_schedule+0x48/0x80
[   40.839406]  bit_wait_io+0x24/0xb0
[   40.839470]  __wait_on_bit+0x5c/0x1a8
[   40.839536]  out_of_line_wait_on_bit+0x94/0xf8
[   40.839624]  __wait_on_buffer+0x48/0x80
[   40.839714]  jbd2_journal_commit_transaction+0xe7c/0x1768
[   40.839808]  kjournald2+0xc8/0x2a8
[   40.839879]  kthread+0x100/0x118
[   40.839948]  ret_from_fork+0x10/0x20
[   40.840035] SMP: stopping secondary CPUs

The panic occurs at ~40s after boot in the jbd2/nvme0n1p1- journaling thread (ext4 filesystem on the rootfs). The stack corruption (corrupted stack end detected inside scheduler) suggests either:

A bug in the guest kernel (6.8.0-94-generic) running under Apple Virtualization.framework on macOS 26.3
Possible rootfs image corruption in the VM bundle

After the kernel panic, the Virtualization.framework vCPU threads continue spinning (the guest enters an infinite halt/panic loop), causing the sustained 300%+ CPU usage until the host eventually reports VZErrorDomain Code=1 "The virtual machine stopped unexpectedly".

Key issue: There's no timeout or watchdog on the host side to detect a panicked guest and kill the VM, so it consumes CPU indefinitely.

The VM bundle is at version 2.1.41 (SDK) but Claude Code is at 2.1.44, which may indicate a version mismatch.

Logs:

~/Library/Logs/Claude/cowork_vm_swift.log
~/Library/Logs/Claude/coworkd.log

github-actions[bot] · 8 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

solomon23 · 8 months ago

Workaround that resolved the issue

Kill the hung VM process:

``kill <pid> # or: killall com.apple.Virtualization.VirtualMachine``

Clear the stale VM state (which contained the corrupted rootfs/session data):

``rm -rf ~/Library/Application\ Support/Claude/claude-code-vm/``

Re-run claude cowork — it re-downloads/recreates a fresh VM bundle and boots successfully.

The issue was likely a corrupted VM image from a prior session. Clearing the cached VM state and letting it rebuild from scratch resolved it.

MarshallOfSound · 7 months ago

We believe this kernel panic has been fixed in the latest version of Cowork v1.1.3541. If you still run into this after updating please ping me below

github-actions[bot] · 7 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.