[BUG] Cowork VM: guest kernel does not enumerate NVMe disks on Intel Mac (x86_64) — hangs after Run /init, VM connection timeout after 60 seconds

Updating to Claude Desktop 1.32352.1 did not help — identical failure signature.

Additional symptom: the guest is also severely throttled by the hypervisor, not
just missing disks. Compare the same benchmark across boots on this machine:

working boot (2026-08-17): raid6: avx2x4 gen() 39522 MB/s
failing boot (2026-08-18): raid6: avx2x4 gen() 7456 MB/s (5x slower)
host log: hrtimer: interrupt took 45794798 ns (45.8 ms)

This was measured with host 1-min load average at 18.75 and no heavy apps
running, so it is not host contention. The missing NVMe enumeration and the
hypervisor stalls are likely the same underlying defect.

Confirming this on a third Intel Mac, with a different macOS version and different hardware from both this report and #87503. Same root cause: the guest kernel boots and then never enumerates its NVMe disks.

The value of this comment is the differences, which between the three of us rule out several variables.

1. Different macOS — rules out the OS version

| | this issue (#87512) | #87503 | mine |
|---|---|---|---|
| macOS | 15.7.7 (Darwin 24.6.0) | Darwin 25.6.0, build 25G76 | 26.6.1, build 25G76 (Darwin 25.6.0) |
| CPU | i5-8279U | i9-9980HK | Intel MacBook Pro |
| RAM | 8 GB | 32 GB | 16 GB, 91% free at failure |
| Free disk | — | — | 37 GB |

Three different macOS versions spanning two major releases, three different CPUs, three different memory sizes. The only thing we share is x86_64 + the 1.32352.x line. It is not a resource problem, not an OS-version problem, and not a specific-machine problem.

2. My last-good and first-bad are ~100 minutes apart, with a version bump in between

This may help if you are bisecting. On my machine 1.32352.0 worked:

2026-08-18 00:14      1.32352.0 installed
2026-08-18 07:09-07:15  VM working normally — cowork_vm_swift.log:
                      "Process spawned: id=oneshot-... failedMounts=0"  (x3)
2026-08-18 08:55:38   clean shutdown — "Guest did stop"
2026-08-18 08:55:56   1.32352.1 installed on quit (ShipIt: "Successfully launched application")
2026-08-18 08:57:29   FIRST FAILURE — every boot since fails identically
2026-08-18 09:25:54   full Mac reboot — no change
2026-08-18 10:33      in-app "reinstall the workspace" (fresh rootfs.img/vmlinuz/initrd) — no change

From main.log:

2026-08-17 23:16:52 [info] [updater] Update downloaded and ready to install { releaseName: 'Claude 1.32352.0' }
2026-08-18 07:07:04 [info] [updater] Update downloaded and ready to install { releaseName: 'Claude 1.32352.1' }

Both other reports name 1.32352.0 as the breaking version. On my machine .0 ran fine for ~7 hours across three successful VM sessions and it broke on .1. Interesting wrinkle: #87503 also reports working "at 07:15 on 18/08/2026", the same window as mine, before their 09:47 update. So either .0 and .1 share the defect and rollout timing differs, or the regression is in .1 and the .0 attributions are off by one. Worth pinning down before bisecting.

3. Same VM bundle hash across machines

#87503 quotes their bundle version as 2a762adfc2eea13eca0d113a2e6452ff00ae3f62.

On my machine, a new and permanently empty directory appeared at:

~/Library/Application Support/Claude/vm_bundles/warm/2a762adfc2eea13eca0d113a2e6452ff00ae3f62/

created at 08:57 on 2026-08-18 — the same minute as my first failure. An older, also-empty warm/ sibling dates to 2026-06-12. Identical hash, and the directory materialises exactly when it breaks. If a warm-bundle path was introduced or changed in this release, that seems worth a look.

4. My good-boot vs bad-boot pair, as a clean diff

Good boot (2026-08-17, coworkd.log.1), after Run /init as init process:

[    2.575608] nvme nvme0: pci function 0000:00:05.0
[    2.576902] nvme nvme1: pci function 0000:00:06.0
[    2.585663] nvme nvme0: 3/0/0 default/read/poll queues
[    2.595184]  nvme0n1: p1 p14 p15

Every failing boot since (coworkd.log) — these are the last lines in the file:

[    1.110328] Run /init as init process
[KERNEL] [    1.183921] NET: Registered PF_VSOCK protocol family
[KERNEL] [    1.193299] virtio_net virtio0 enp0s1: renamed from eth0
[    1.216683] virtio-pci 0000:00:0a.0: [drm] fb0: virtio_gpudrmfb frame buffer device
[    1.566179] clocksource: Switched to clocksource tsc
[KERNEL] [    1.745359] xor: automatically using best checksumming function   avx

grep -cE "nvme|xhci" from Run /init to EOF returns 0 on every failing boot. virtio-net and virtio-gpu still enumerate; only the disk controllers are missing — matching this issue exactly.

Also worth noting: the host-side create_vm_config block is byte-identical between my last good boot and every failing one — same rootfs and sessiondata paths, same MAC, 4 vCPU / 4 GB, Boot: EFI (GRUB), Added smol-bin.img as read-only virtio-blk device. The host thinks it succeeded (Linux VM started successfully, vm_boot completed) and reports no error at any layer: the Virtualization framework unified log is clean, no sandbox or TCC denial, no APFS or I/O error, no crash report.

5. Scheduled tasks are collateral damage — I don't think this has been mentioned

The scheduled-task engine depends on the same VM, so it is silently dead too:

2026-08-18 10:32:05 [info] [ScheduledTasks] VM not ready (tick 1), requesting startVM
2026-08-18 10:34:05 [warn] [ScheduledTasks] startVM failed: Error: VM connection timeout after 60 seconds
2026-08-18 10:37:38 [warn] [HostLoop] VM boot failed; bash proxy unavailable: VM connection timeout after 60 seconds

It retries on a ~5 minute loop indefinitely, with no user-facing signal that automation has stopped. For anyone running unattended scheduled work, this outage is invisible until output is missing — which raises the severity beyond "Cowork is unusable."

6. Repairs that did not help here either

1. Restart the app (multiple)
2. Full Mac reboot
3. In-app "reinstall the workspace" — re-downloaded rootfs.img, vmlinuz, initrd, checksum-validated
4. Killed the lingering com.apple.Virtualization.VirtualMachine process

I did not hand-delete the bundle, since #87503 and #67066 already establish that path as exhausted. One triage detail: the in-app reinstall replaces rootfs.img / vmlinuz / initrd but does not replace sessiondata.img, and does not clear the warm/ directories.

I can also confirm the secondary oddity reported here: Direct-boot artifacts not present in bundle; using EFI (GRUB) boot fires even though vmlinuz (15,014,280 bytes) and initrd (28,165,330 bytes) are both present in the bundle — byte-for-byte the same sizes quoted in this issue.

One ask

Is there a supported way to pin or reinstall a specific previous desktop version? There is no copy of the working build left on this machine and no local APFS snapshot to recover from, so there is no rollback and no way to keep working while this is open. #87503 pins their last-known-good at 1.30096.5.

Happy to run any diagnostic and send full logs — I have the guest console intact for both a working and a failing boot.

Fourth Intel Mac here, and I think the .0-vs-.1 confusion in this thread resolves cleanly. The app build is not the variable — the guest bundle is.

Same hash across all four machines: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62

#87601 has a clean bisect on one machine with the app build held constant: every start on 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a succeeded (nvme0n1 and nvme1n1 enumerate, EXT4 mounts, coworkd connects), every start on 2a762adf… hung. No app update between the two.

Confirmed on my machine — both hashes present, with the rollover timestamped.

drwx------  2  18 Aug 08:01  2a762adfc2eea13eca0d113a2e6452ff00ae3f62
drwx------  2  12 Jun 07:20  6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a

My first failure was 08:02:14 CEST. The known-bad warm directory was created at 08:01 — one minute earlier. That matches @hklorman exactly, whose warm directory appeared in the same minute as their first failure at 08:57.

Two independent machines, both with the warm directory created immediately before the first hang, on different app builds. Note also that the known-good directory from 12 Jun is still present — these persist rather than being replaced. Both are empty here, but the app evidently still tracks the identifier, which may matter if a pin mechanism is considered.

Why the onsets disagree. The bundle isn't flipped globally at one moment — it's fetched per machine at that machine's next check, which the warm-directory timestamps make visible.

| machine | first hang | app build at onset |
|---|---|---|
| @daotuan152 (i5-8279U) | 17 Aug | 1.32352.0 |
| mine (CEST) | 18 Aug 08:02:14, warm dir 08:01 | 1.32352.1 |
| #87601 second reporter (AEST) | 18 Aug 16:04 = 06:04 UTC | 1.32352.1, unchanged across rollover |
| @hklorman | 18 Aug 08:57, warm dir same minute | 1.32352.1, minutes after install |

1.32352.0 both works (@hklorman ran it ~7 hours across three successful sessions) and fails (@daotuan152). A build that does both cannot be the variable. The hash is the only constant across all four machines.

One correction on the throttling. @daotuan152, my failing boots are not slow — raid6: avx512x2 gen() 62116 MB/s, full speed — and the second reporter on #87601 sees zero soft lockups across roughly 20 failed boots. Both of us hang outright with no degradation beforehand. The hypervisor stalls you're seeing therefore look like a separate condition on some machines rather than part of this defect, and I'd suggest not conflating the two while triaging.

Quick check for anyone else reporting here:

ls -la ~/Library/Application\ Support/Claude/vm_bundles/warm/

The directory names are bundle hashes and their timestamps are your rollover moment. This has now pinned the onset precisely on two machines and is faster than comparing version numbers.

The ask, seconded: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a is demonstrated working on Intel x86 as recently as 18 Aug 05:49 UTC. Republishing it for x64, or providing a way to pin a bundle, would unblock every affected machine in these threads. Rolling back the app does not help — the bundle is fetched independently of the build, so a rolled-back app fetches the same broken bundle.

Cross-referencing the related reports so they're linked from here: #87601, #87503.

Also hitting this on an Intel Mac. Same signature: VM boots host-side, guest never enumerates the NVMe disks, hangs silently after Run /init as init process, host times out at 60s on guest_vsock_connect.

Last successful boot on my machine: Aug 16, 12:36 AM UTC. Every attempt since (40+ across two days) fails identically, including after:

• Multiple full machine reboots
• Deleting and rebuilding the VM bundle from scratch
• Deleting and rebuilding the local SDK directory (claude-code-vm)

One boot attempt also hit a hard VZErrorDomain Code=1: Internal Virtualization error after sitting hung for 8+ minutes, which matches what's described here.

On the CPU/fan issue raised in this thread: I can confirm it. My own logs show the VM completing vm_boot 25+ separate times across a two-hour window, each a fresh 4-vCPU Linux boot torn down after only 1-10 minutes. The app's main process also stalls repeatedly during this cycle (e.g. "main process blocked for 4183ms"), and system-wide available memory dropped from 17.3GB to 7.6GB over about 75 minutes while stuck in the restart loop, consistent with teardown/rebuild not fully releasing resources between cycles. Fan's been at full blast the whole time.

Environment: Intel Mac (x86_64), Claude Desktop 1.32352.1 (6c6aa5), built 2026-08-18T00:07:03.000Z. Still broken on this build, same as reported in #87601, so the .1 point release didn't fix it. gvisor networking, EFI/GRUB boot path (Direct-boot artifacts not present in bundle).

The VM was continuously running with confirmed successful guest activity as late as 18:33:12 local on Aug 17 — under 5 minutes before it was cleanly stopped at 18:38:36 to install the update. The update completed at 18:38:56 (1.30096.5 → 1.32352.0), and the very first VM boot afterward, at 18:40:12, is the first guest_vsock_connect that never completes. Every attempt since has failed the same way.

2026-08-17 18:33:12  SDK installed successfully
2026-08-17 18:38:36  Stopping VM (isAppQuit: true) — shutting down for the update
2026-08-17 18:38:37  VM stopped successfully
2026-08-17 18:38:56  [updater] Version changed: 1.30096.5 → 1.32352.0
2026-08-17 18:40:12  guest_vsock_connect started — never completes, first attempt of the ongoing failure

Hitting the same issue. Based on your experience, how long do you expect the fix to be rolled out?

@krboswell posted the promotion verbatim on #87601, which settles the rollout question and corrects the estimate I gave earlier in this thread. I had put the switch at ~06:00 UTC 18 Aug based on two machines; that was two machines happening to check in at the same time, not a global flip.

From his log:

[Bundle:status] rootfs.img version mismatch: have=6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a, want=2a762adfc2eea13eca0d113a2e6452ff00ae3f62
[download:1] Starting download from https://downloads.claude.ai/vms/linux/x64/2a762adfc2eea13eca0d113a2e6452ff00ae3f62/rootfs.img.zst

Rollover times so far, all to the same hash:

| reporter | rollover (UTC) | app build at rollover |
|---|---|---|
| @charles0106 | ~16 Aug (last good boot 00:36) | — |
| @daotuan152 | 17 Aug | 1.32352.0 |
| @krboswell (#87601) | 17 Aug 22:02 | 1.32352.0 |
| me | 18 Aug 06:02 | 1.32352.1 |
| @hklorman | 18 Aug 06:57 | 1.32352.1 |

A staged rollout spanning at least two and a half days, fetched per machine at its next check — not a single event. Two consequences: the affected population is still growing, since any Intel Mac still on 6d1538ba… will pick up the bad bundle at its next promotion; and the app version is irrelevant, since the same promotion happened under .0 and .1.

His break is unusually clean: a normal Cowork session ran on 6d1538ba… until 16:32, shut down gracefully at 16:57, and the very first boot on 2a762adf… at 17:01 failed. No boot has succeeded since.

A better diagnostic than the warm/ check I posted earlier. @krboswell's trick:

stat -f "%Sm" ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/vmIP

The host only writes vmIP after a successful guest handshake, so its mtime is your last working VM — and its absence means a bundle has never handshaked at all.

His fresh-identity test closes a gap the app cannot close itself. Renaming the whole vm_bundles/ directory produced a new machineIdentifier, new MAC, new efivars, a brand-new 4 MiB sessiondata.img and a re-downloaded checksum-validated rootfs — and failed identically. That matters because in-app repair always preserves sessiondata.img:

[deleteVMBundle] Reinstall files deleted (sessiondata.img and compressed cache preserved)

So no amount of in-app repair could ever have ruled out accumulated session state. It is now ruled out. His previous sessiondata had grown to 2.14 GiB since March; a fresh 4 MiB one fails the same way.

On rollback: it is gone locally. His log shows Deleting old rootfs.img to free disk space and an empty warm directory for 6d1538ba…. Mine is empty too. The known-good image no longer exists on any affected machine, so there is no client-side path back. Republishing 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a on the x64 channel is the only remaining route to a working Cowork on Intel — and retaining the previous image in the warm cache would make a failed promotion recoverable in future.

He also confirms codesign -v --deep --strict exits 0, so the disclaimer spawn failure seen on startup failures is not app-bundle corruption.

Adding warm-directory birth times from the machine with the bisect on #87601 (Core i9-9980HK, macOS 26.6.1, 1.32352.1 unchanged across the rollover). These refine the warm/ diagnostic slightly: birth time and modification time mean different things, and on this machine they're twelve minutes apart.

warm/2a762adfc2eea13eca0d113a2e6452ff00ae3f62 birth=Aug 18 15:53:47 mod=Aug 18 16:05:51
warm/6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a birth=Jun 12 07:08:59 mod=Jun 12 14:53:10

Local time is AEST (UTC+10), so in UTC:

05:49:27 Guest connected — good bundle running normally
05:53:47 warm/2a762adf… created — bad bundle fetched while the good VM was still up
06:03:47 clean shutdown, guest stopped in 1s
06:04:37 first VM start logged on 2a762adf…
06:05:51 warm/2a762adf… modified — same second as the first failed startVM

The fetch does not break the running VM. The download landed at 05:53:47 and the session carried on working for ten more minutes until it was shut down normally. The break comes at the next boot, when the new bundle is promoted.

That explains why @Jensebeen and @hklorman both saw the warm directory appear one minute before their first failure while mine appears eleven minutes before: with no session running, fetch and promotion collapse into the same moment. So birth time is when your machine downloaded the bad bundle; modification time is when it first booted from it. For pinning onset, the modification time is the one that matches the first failure.

Also confirming the persistence @Jensebeen noted: my known-good 6d1538ba… warm directory is still present, born 12 June, and was in service for two months. Both directories are empty here too.

@dawooddren the birth/mod distinction holds, but my numbers don't fit the "collapse into one moment without a session" part:

warm/2a762adf…  birth=Aug 18 01:49:08  mod=Aug 18 08:01:14   (CEST → 23:49:08 and 06:01:14 UTC)
warm/6d1538ba…  birth=Jun 11 22:05:08  mod=Jun 12 07:20:51

Six hours apart, with no session running in between — my last successful boot was the previous evening at 19:48 CEST and nothing ran overnight. So the gap isn't explained by a session keeping the old bundle alive.

Note the same shape on the good bundle back in June: born late evening, modified the next morning. Both look like an overnight fetch that only takes effect at the user's next start.

That also reorders the rollout table. My download landed at 23:49 UTC on 17 Aug — six hours before your 05:53 UTC fetch, while your machine was still working normally. So the staggering is in the promotion, not the download: several of us may have been carrying the bad bundle on disk for hours before it was ever booted. If others post birth times alongside mod times, that should show up.

Practical upshot for anyone checking: stat -f "birth=%SB mod=%Sm" ~/Library/Application\ Support/Claude/vm_bundles/warm/* — mod time is your first boot on the bundle, birth time is when it arrived.

Additional impact worth recording: on macOS, the outage also degrades the desktop app's file tools, not just code execution. I don't think this has been noted in any of the related threads.

Setup: Intel Mac (i9-9980HK), macOS 26.6.1, Claude Desktop 1.32352.1, bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62. Working folder is a Dropbox directory under the macOS File Provider mount at ~/Library/CloudStorage/Dropbox/….

With the workspace down, Read fails on most files in a connected folder with:

EPERM: operation not permitted, open '/Users/USERNAME/Library/CloudStorage/Dropbox/PROJECT/NOTES.md'

This is not a materialisation problem. The same file reads fine from the shell:

$ head -c 200 ~/Library/CloudStorage/Dropbox/PROJECT/NOTES.md
Project notes
Section heading
(file contents print normally)

ls -lO shows no dataless flag, and the behaviour is unchanged after marking the entire folder Make Available Offline. So the bytes are local and readable at OS level; the app's own file tool is what refuses.

Two further observations:

Glob/enumeration never works on these paths. A recursive glob for **/*.md across a folder containing thousands of Markdown files returns nothing, so the tree can't be explored at all — every file has to be named explicitly.
Read succeeds intermittently. Two files opened normally during the same session in which five others returned EPERM, with no pattern by depth, directory or file type that I could identify.

Impact: for anyone whose working files live in Dropbox, iCloud Drive, OneDrive or Google Drive — i.e. anyone using the macOS File Provider — the outage also takes away Claude's ability to read those files. The files themselves are fine and open normally in any other application; it is specifically the app's file tools that fail. The current framing of "Cowork is unusable / scheduled tasks silently dead" understates it: reading and editing ordinary Markdown and text files is also unreliable, which for non-developer users is the primary use of the product.

Happy to provide the full sequence of failing and succeeding paths if useful.

Copy everything below the line into a comment on #87512.

Resolved here by an app update — with the bundle hash unchanged.

Machine: MacBook Pro (2020), Intel Core i9-9980HK, 32 GB. macOS 26.6.1 (Darwin 25.6.0, build 25G76).

After updating Claude Desktop from 1.32352.1 to 1.32885.1, the Cowork workspace boots and connects normally on this machine for the first time since 18 Aug:

Linux 6.8.0-136-generic
/dev/nvme0n1p1 9.6G 5.1G 4.5G 53% /

nvme0n1p1 enumerates and mounts, and coworkd connects over vsock. Shell commands execute normally.

The guest bundle is unchanged. cowork_vm_node.log still reports:

2026-08-19 10:00:21 [info] [VM:start] Bundle version: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62
2026-08-19 10:02:41 [info] [VM:start] Bundle version: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62
2026-08-19 10:10:34 [info] [VM:start] Bundle version: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62

That is the same hash that failed on every boot across the machines in this thread and in #87601.

What that implies about the cause. The defect was not in the guest image alone. The same bundle that would not enumerate its NVMe disks under 1.32352.1 does so under 1.32885.1, so the image evidently required host-side disk-attachment behaviour the older app build didn't provide. That accounts for two things that were otherwise puzzling:

Deleting the bundle and re-downloading never helped — it re-fetched the same image, and the missing half of the pairing was on the host.
The bisect on my machine (#87601: every boot on 6d1538ba… succeeded, every boot on 2a762adf… hung, app build constant at 1.32352.1) was a correct observation but an incomplete diagnosis. The bundle was the proximate trigger; the app was the other half.

For anyone still affected: update the app rather than touching the bundle. Check with

defaults read /Applications/Claude.app/Contents/Info.plist CFBundleShortVersionString

and confirm the boot with

grep -E "Guest connected|Connection timeout" ~/Library/Logs/Claude/cowork_vm_swift.log | tail -3

A Guest connected line with a current timestamp means it's through.

Cross-referencing #87601, #87503, #87604 and #87567, which all describe this failure on Intel Macs.