[BUG] Cowork VM connection timeout after update to 1.32352.0 on Intel Mac (guest never connects)

Update since filing. Two more repair paths tried, both failed, and the failure mode has shifted in a way that points somewhere specific.

d. Full reboot of the Mac. No change. The retry loop resumed immediately at the same fixed 5 minute interval: 12:18:55, 12:22:13, 12:27:13, 12:32:13, 12:37:13, 12:42:13. All failing at guest_vsock_connect.

e. Clean reinstall. Deleted /Applications/Claude.app entirely and installed a fresh download of 1.32352.0. No change. Same bundle version (2a762adfc2eea13eca0d113a2e6452ff00ae3f62), loop resumed at 12:47:13, 12:52:04, 12:54:04.

This also rules out a damaged app bundle from the ShipIt swap, which was my leading theory. The helper spawn failure persists byte-identically on a clean install:

12:53:05 [error] [networkDiagnostics] Failed to run /usr/bin/pgrep:
Error: Failed to spawn /usr/bin/pgrep (via disclaimer):
/Applications/Claude.app/Contents/Helpers/disclaimer exited with code 1

So that helper error is an unrelated bug, not corruption.

The failure has escalated from vsock to boot itself

After the reinstall, it stopped failing at guest_vsock_connect and started failing at vm_boot. The ordering is the interesting part:

12:52:04 [VM:steps] stop_existing_vm started
12:52:31 [VM:shutdown] App quit, stopping VM (instance: ce1ce1f8-3356-4b79-b84a-1c71eb89f88f)...
12:53:04 [VM:steps] stop_existing_vm completed (60217ms)
12:53:04 [VM:steps] vm_boot started
12:53:05 [error] [VM:start] VM boot failed: Error Domain=VZErrorDomain Code=1
"The virtual machine failed to start."
UserInfo={NSLocalizedFailure=Internal Virtualisation error.,
NSLocalizedFailureReason=The virtual machine failed to start.}
12:53:05 [info] [VM:start] Skipping auto-reinstall (already attempted once)

stop_existing_vm burned the full 60 second timeout and then "proceeded with cleanup" without the VM having actually stopped. The very next boot failed outright with an internal virtualisation error.

This reads as leaked virtualisation resources. Every teardown in this loop hits the timeout, so each retry stacks on an instance the host still considers live, and eventually the framework refuses to start another. #23830 reports the same shape on macOS, with the vmnet gateway IP incrementing on every retry (67.1, 68.1, 69.1...). Same leak, different symptom.

If that is what is happening, the no-backoff retry loop is not just wasteful, it is actively making the failure worse over time.

Rollback is a one-way door

Worth flagging as a severity point. The app auto-updated without prompting, the update broke the feature, and there is no supported way back:

The previous bundle ShipIt moved to /var/folders was cleared by a reboot during troubleshooting
I do not run Time Machine, so no snapshot exists
The versioned download endpoint returns not_found_error

Unless a user happens to have a backup, an auto-update that breaks Cowork is unrecoverable without Anthropic handing over the old build. Two things would turn this from an outage into an inconvenience: a published archive of previous builds, or an in-app "revert to previous version" that uses the bundle ShipIt already sets aside during the swap.

Current state

Roughly 40 consecutive failed cycles between 09:49 and 12:54. Zero successes. I have quit the app to stop it cooking the CPU, so the loop is paused rather than resolved. Happy to run any diagnostic or attach full logs.

Github comment 87503 · MD

Confirming on a third Intel model — Mac Pro 2019 (MacPro7,1, Xeon, x86_64), macOS 15.7.7 (24G720). Still reproduces on 1.32352.1.

Same regression and timeline as OP:

Healthy on 1.30096.5 with bundle 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a (in use since 2026-06-12); the workspace was still serving processes at 2026-08-18 00:27 +0100.
Auto-update to 1.32352.0 installed at 00:50 +0100; VM bundle replaced with 2a762adfc2eea13eca0d113a2e6452ff00ae3f62.
Every start since then: vm_boot completed (~160ms) → guest_vsock_connect never completes → Startup failed: Error: VM connection timeout after 60 seconds, last completed step vm_boot. ~130 consecutive failures so far, retry loop every ~5 minutes (same background CPU burn as described above).
Auto-update to 1.32352.1 (05:59 +0100 today) did not fix it — bundle hash unchanged, identical failures continue (latest at 10:10 +0100).
In-app workspace reinstall, the app's one automatic bundle reinstall, full macOS reboot, new sessions — no effect. File-bridge tools work fine; only the VM is affected.

One data point I haven't seen in this thread yet: at 02:43:19 +0100 an attempt took down Apple's Virtualization XPC helper itself — com.apple.Virtualization.VirtualMachine crashed with EXC_BAD_INSTRUCTION (SIGILL, "Illegal instruction: 4") ~160 ms after the XPC service launched, faulting queue com.apple.virtualization.virtual-machine (instruction stream ends in ud2, i.e. a deliberate internal trap), and the host logged VZErrorDomain Code=1 at the same second. Sanitized crash report (.ips) plus log excerpts (updater timeline, boot-step traces, vzgvisor) are attached.

Consistent with #87512 (guest kernel never enumerates the NVMe root disks on x86_64, initramfs waits for root=LABEL=cloudimg-rootfs forever) and #87567 (x86_64 image set missing initrd-micro.zst, arm64 set unaffected).

Also reproduces on 1.32352.1, one build later than the version in the
original report. Second Intel Mac, independent of OP.

MacBook Pro (Intel), macOS 26.5.2 (25F84), Claude Desktop 1.32352.1
(CFBundleShortVersionString). Note OP is on build 25G76, so this does
not appear tied to a single macOS release. Cowork worked normally
earlier in the day on 18/08/2026 and has failed on every attempt
since. The user-facing error is:

Workspace unavailable. The isolated Linux environment failed to
start (VM connection timeout after 60 seconds).

Some attempts instead report "Workspace still starting. The isolated
Linux environment is booting in the background", but it never
completes and reverts to the timeout above.

cowork_vm_node.log shows the identical stall point — vm_boot completes
in ~300ms, guest_vsock_connect starts, and nothing ever connects:

2026-08-18 13:07:51 [info] [VM:steps] vm_boot started
2026-08-18 13:07:51 [info] [VM:steps] vm_boot completed (309ms)
2026-08-18 13:07:51 [info] [VM:steps] guest_vsock_connect started
2026-08-18 13:08:51 [error] [VM:start] Connection timeout, last
completed step: vm_boot
2026-08-18 13:10:10 [info] [VM:steps] vm_boot started
2026-08-18 13:10:11 [info] [VM:steps] vm_boot completed (311ms)
2026-08-18 13:10:11 [info] [VM:steps] guest_vsock_connect started
2026-08-18 13:11:11 [error] [VM:start] Connection timeout, last
completed step: vm_boot

No "Guest connected" line appears anywhere in the log. Every cycle is
exactly 60 seconds from guest_vsock_connect started to timeout.

Non-fixes, matching the original report:

• Full quit (Cmd+Q) and relaunch, several times
• Deleting ~/Library/Application Support/Claude/vm_bundles
• Deleting ~/Library/Application Support/Claude/claude-code-vm

One data point not in the original report: a full macOS restart also
does not fix it. Rebooting the host left the behaviour completely
unchanged, which rules out stale host-side state on the Mac itself.

Minor divergence on the retry loop: my intervals were irregular rather
than a fixed 5 minutes (gaps of roughly 2, 10 and 20 minutes in the
excerpt above). I suspect retries are also triggered on demand by
session activity, not only by a background timer.

Summary: two independent Intel Macs, two adjacent app builds
(1.32352.0 and 1.32352.1), two different macOS builds, same stall at
guest_vsock_connect, same ineffective remedies.

Happy to attach full cowork_vm_swift.log, cowork_vm_node.log and
coworkd.log if useful.

Confirming on another Intel variant — iMac18,3 (2017, x86_64), macOS Sequoia
15.x via OpenCore Legacy Patcher, Claude Desktop 1.32352.1, SDK 2.1.229.
Same timeline as OP: healthy through the night of Aug 17, app auto-updated
00:33 EDT Aug 18, bundle replaced 6d1538ba… → 2a762adf…, and every boot
since fails at guest_vsock_connect (~81 attempts).

A few data points I haven't seen in this thread yet:

• The "your network traffic may be routing through a VPN" error is a false

positive: 79 of my 81 failures logged it, but Tailscale is installed and
disconnected (scutil --nc list: Disconnected; utuns link-local only).

• sessiondata.img is not involved: debugfs shows the filesystem clean, and

its last-mount timestamp is my last successful boot — failing boots never
get far enough to mount it.

• The app's own automatic bundle reinstall (fresh rootfs/vmlinuz/initrd for

2a762adf at 00:46) changed nothing, and the second app update (06:56)
changed nothing.

• Possible early warning: my last successful guest_vsock_connect

(Aug 17, on the old bundle) took ~25 s vs. the usual few seconds.

• Guest console ends right after the raid6/xor: … avx lines, then only

drain_vmap_area_work hogged CPU and hrtimer: interrupt took 10935829 ns
warnings — matching the stall point in #87567 and (more mildly) the
hypervisor-stall symptoms in #87512.

With OCLP-Sequoia now in the mix alongside 15.7.7 / 25G76 / 26.5.2, the OS
is thoroughly ruled out as the variable — everything points at the x86_64
image set under bundle 2a762adf… (per the hash analysis in #87567).

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).

Reproduced on a third Intel config (i9-9880H, 16 GB, macOS 26.5.1) — same
guest_vsock_connect 60s timeout on bundle 2a762adf…, on the first boot after
the 1.32352.0 update, with no successful boot since.

Detailed logs in #87601, including a correction to the rollout estimate there:
my updater fetched 1.32352.0 at 2026-08-17 21:03 UTC and the first failure
was 22:02 UTC — roughly 9 hours before the ~06:00 UTC 18 Aug figure.

Two points from that comment specific to this thread:

• The disclaimer / pgrep spawn failure you documented reproduces here, and

codesign -v --deep --strict /Applications/Claude.app exits 0 — so it isn't
app-bundle corruption.

• A full vm_bundles/ rename — new machineIdentifier, new MAC, fresh 4 MiB

sessiondata.img, re-downloaded and checksum-validated rootfs.img — fails
identically. Worth noting because the in-app auto-repair logs
Reinstall files deleted (sessiondata.img and compressed cache preserved),
so it structurally cannot test that path. Accumulated session state is ruled out.

Combined with #87512 (i5-8279U, 8 GB, macOS 15.7.7), this spans two major macOS
versions and 8 → 16 GB RAM, so neither the OS version nor memory pressure is the
variable.

Can confirm the same issues on my 2018 Intel Macbook Pro. This started yesterday and I've tried deleting the vm_bundle folder and letting it redownload/unpack to 22.85GB, deleting the claude_code_vm folder, reinstalling claude, deleting the claude library folder and reinstalling claude, first aid on disks, killing the background vm processes via terminal (sudo pkill -9 -f "Virtualization" && pkill -9 -f "coworkd"), adding claude to firewall as explicit allowed, setting claude_desktop_config.json with "networkMode": "nat".

The only things I have not tried is reinstalling the mac or erasing and reinstalling the mac.

Edit: Updated to Claude 1.32352.1 (6c6aa5) 2026-08-18T00:07:03.000Z that came out a couple hours ago too, didn't help.

Resolved for me in 1.32885.1.

Importantly, 1.32352.1 did not fix it, which matches what the second reporter above found on their Intel Mac.

Timeline from this morning, 19/08/2026:

06:43:29 [updater] Version changed since last launch: 1.32352.0 -> 1.32352.1
06:43:33 startVM called -> guest_vsock_connect started, never completed
08:06:33 startVM called -> guest_vsock_connect started, never completed
08:08:26 [updater] Version changed since last launch: 1.32352.1 -> 1.32885.1
08:08:37 startVM called
08:08:38 VM startup step: guest_vsock_connect started
08:08:41 Guest connected
08:08:44 Network status: CONNECTED
08:08:44 Guest ready

Two failed starts on 1.32352.1, then the first start on 1.32885.1 connected in about 4 seconds. That is back in line with the pre-regression baseline (6 seconds on 16/08).

I also updated macOS in the same window, but the 08:06:33 failure happened after the OS update while still on 1.32352.1, so the app update is what fixed it.

The retry loop has stopped, the VM is healthy, and workspace commands run normally again. Total outage on this machine was roughly 22 hours, 09:49 on 18/08 to 08:08 on 19/08.

Happy for this to be closed. Two things from the thread that may still be worth splitting into their own issues, since they are about how the failure behaved rather than the failure itself:

No backoff on the retry loop. A permanently failing VM retried every 5 minutes indefinitely, and each cycle cost a boot, 60 seconds of polling, a log show diagnostic sweep and a 60 second teardown that always timed out. That is what made this visible to me: I went looking for why my fans were loud, not because I noticed Cowork was broken.
No rollback path. The app auto-updated without prompting, the update broke the feature, and there was no supported way back to the previous build. Exposing a revert that uses the bundle ShipIt already sets aside during the swap would turn an outage like this into an inconvenience.

Thanks to whoever fixed it.

How did you get that version (1.32885.1)? I can't see it even when I try checking for updates.

No MDM pin involved — /Library/Managed Preferences/ has nothing for Claude, and
the server is returning a normal "no update" rather than anything blocked.

Host: i9-9880H, macOS 26.5.1, currently on 1.32352.1.

Since @jasonpadman is also on Intel and already has 1.32885.1, this looks like a
staged rollout rather than an arch gap. Worth holding this open until the fix is
generally available on x64 — right now the only build Intel users can obtain is
the broken one. If there's a direct link to 1.32885.1 or a way to opt into the
rollout early, that would unblock people today.

Confirmed fixed in 1.32885.1, and the NVMe diagnosis here was exactly right.

Host: i9-9880H, macOS 26.5.1. Updated 1.32352.1 → 1.32885.1 at
2026-08-19 00:15 UTC; the VM connected on the first boot afterward.
lsblk inside the guest now shows all three disks, with both NVMe
devices enumerating:

NAME SIZE TYPE MOUNTPOINT
vda 23M disk
nvme1n1 10G disk
├─nvme1n1p1 9.9G part /
├─nvme1n1p14 4M part
└─nvme1n1p15 106M part
nvme0n1 10G disk /sessions

On the broken build only vda appeared, which is why initramfs hung
indefinitely on root=LABEL=cloudimg-rootfs.

Note this reproduced on macOS 26.5.1 as well as your 15.7.7, so it was
never OS-version dependent — purely the x86_64 guest image.

The rollout was also staged: as of 22:57 UTC on 18/08 neither the update
feed nor the direct website download offered 1.32885.1 on x64. It reached
me at 00:11 UTC on 19/08, roughly 16 hours after the first reports.