[BUG] Cowork on Intel Mac: guest bundle 2a762adf… hangs in early init — bisected on two machines, rolled out ~06:00 UTC 18 Aug

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Edit 18 Aug — the headline finding below is superseded. The variable is the guest bundle, not the app build. Bundle 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a works on Intel x86; 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 hangs. See the bisect in the comments. Original text kept below for the record.

This is a Claude Desktop Cowork issue, not the Claude Code CLI.

The Cowork workspace fails to start on every attempt with "VM connection timeout after 60 seconds". The host-side VM boots in ~335 ms, but the guest hangs during early kernel init and never starts coworkd, so guest_vsock_connect times out.

Hardware is an Intel Mac (x86_64), so the app uses smol-bin.x64.img and the EFI/GRUB boot path.

~~The key finding: the failure is identical with the pre-update guest image AND with a freshly downloaded post-update image. The app's own auto-reinstall ran at 08:02 and pulled new artifacts at 09:03; the first failure was at 08:02, an hour earlier. The guest image is therefore not the variable.~~

Corrected. Both images on this machine carry the same bundle hash 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, so this did not test two different bundles — the app re-downloads the same broken one. A bisect on a second Intel Mac (in the comments) isolates the variable cleanly: every start on 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a succeeded, every start on 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 hung, with the app build unchanged across the rollover.

Timezone-corrected onset across both machines:

• second machine, last good boot on the good bundle: 15:49 AEST = 05:49 UTC
• second machine, first hang on the bad bundle: 16:04 AEST = 06:04 UTC
• this machine, first hang: 08:02 CEST = 06:02 UTC

The second machine had no VM start between 15:49:16 and 16:04:37 AEST, so the tightest bound on the rollover is between its last good boot at 05:49 UTC and my first hang at 06:02 UTC — a thirteen-minute gap.

Two machines on different continents, different Intel hardware, and different macOS versions (26.5.2 and 26.6.1) failed within that window. That points to a server-side bundle rollout, not to anything local. The second machine also ran 1.32352.1 successfully for fifteen hours after the app update, which rules the app build out entirely.

Closest prior report: #23830 (macOS, same guest_vsock_connect / vm_boot signature, triggered by a macOS 26.3 beta rather than an app update; now stale). The Windows-on-ARM timeout reports (#67066, #48370, #39161, #47737, #65128) hang at add_plan9_shares, which is a different step.

What Should Happen?

Guest init completes and coworkd connects over vsock, as it did through 17 Aug 2026 19:48 on the same machine and the same macOS version.

Error Messages/Logs

Host — cowork_vm_node.log (identical on every attempt):
[VM:steps] vm_boot started
[VM:steps] vm_boot completed (335ms)
[VM:steps] guest_vsock_connect started
[VM:start] Still waiting for guest connection... 10419ms elapsed, 20 polls
[VM:start] Still waiting for guest connection... 50862ms elapsed, 100 polls
[VM:start] Connection timeout, last completed step: vm_boot
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds
[VM:start] Skipping auto-reinstall (already attempted once)

Guest — coworkd.log. Kernel boots, then output stops at ~1.8s with no panic:
[    1.251753] Run /init as init process
[    1.340314] NET: Registered PF_VSOCK protocol family
[    1.792150] raid6: using algorithm avx512x2 gen() 62116 MB/s
[    1.812309] clocksource: Switched to clocksource tsc
[    1.817539] xor: automatically using best checksumming function   avx
<no further output; one attempt emitted a single line at t=25s about a timekeeping watchdog, nothing more>

PF_VSOCK registers successfully inside the guest. No coworkd line has been written since 17 Aug 19:48.

Last successful boot on 17 Aug reached:
[coworkd] found session disk by label: /dev/nvme1n1
[coworkd] user recovery complete: recovered=361 skipped=1 failed=0
[coworkd] connected, waiting for commands

Guest kernel: Linux 6.8.0-136-generic, x86_64.

Shutdown also times out — cowork_vm_swift.log:
[VM] Stopping VM (isAppQuit: true)...
[VM] VM shutdown taking longer than 10s, showing panel
[VM] Timeout waiting for VM to stop (state: 1), proceeding with cleanup

Possibly relevant, logged on every start despite vmlinuz and initrd being present in the bundle:
Direct-boot artifacts not present in bundle; using EFI (GRUB) boot

Steps to Reproduce

1. Intel Mac (x86_64) running macOS 26.5.2, Claude Desktop 1.32352.1.
2. Let the app fetch guest bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 (currently unavoidable — see below).
3. Open Claude Desktop and switch to the Cowork tab.
4. Wait 60 seconds.
5. "Failed to start Claude's workspace — VM connection timeout after 60 seconds" appears.
6. Repeats on every attempt, roughly every 5 minutes while the tab is open.

Ruled out, each verified:

• Network/VPN: failing step is host-local vsock; PF_VSOCK registers in the guest; networking mode is gvisor user-mode and uses no host interface. The network diagnostics dump the app writes after each failure is misleading here.
• Session data: coworkd mounts the session disk, and coworkd never starts. Removing sessiondata.img changed nothing (confirmed on both machines).
• VM identity: deleting machineIdentifier, gvisorMacAddress and vmIP changed nothing.
• Workspace reinstall: app auto-reinstall at 08:02 and a manual reinstall both had no effect — both re-fetch the bad bundle.
• Restarts: app restart and machine restart (09:44, after first failure at 08:02), no change.
• macOS: no OS update since 26.5.2 on 10 Jul 2026, no background security update since 17 Mar 2026. The second machine runs 26.6.1, so the OS version is not the variable either.
• App build: the second machine ran 1.32352.1 successfully for fifteen hours after the update, until the bundle rollover.
• Damaged install: codesign --verify --deep --strict reports "valid on disk" and "satisfies its Designated Requirement".
• Download corruption: the second machine deleted the whole bundle and let the app re-download; it re-fetched the same bad bundle and failed identically.
• Disk space: sufficient.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Guest bundle 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a (the app build is not the variable). Last successful workspace start on this machine: 17 Aug 2026, 19:48 CEST.

Claude Code Version

N/A — Claude Desktop 1.32352.1 (Cowork). Claude Code CLI not installed.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Machine: MacBook Pro, Intel x86_64. macOS 26.5.2 (build 25F84), installed 10 Jul 2026.
Claude Desktop 1.32352.1, universal binary; the app selects smol-bin.x64.img.
VM config: 4 CPUs, 4 GB memory, EFI (GRUB) boot, gvisor user-mode networking.

Bundle hashes, kept distinct because the bisect rests on them:

• known-good: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
• known-bad: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62

This machine is on the known-bad bundle.

Timeline (CEST, UTC+2):

• 17 Aug 19:48 — last successful start
• 18 Aug ~00:14 — app resources replaced (smol-bin.*.img timestamps); app update landed overnight
• 18 Aug 08:02 (06:02 UTC) — first failure, before any user action
• 18 Aug 08:02 — app writes .auto_reinstall_attempted and reinstalls the workspace
• 18 Aug 09:03 — guest artifacts re-downloaded; 09:38 decompressed; same hash
• 18 Aug 09:04 onward — failures continue unchanged

Two further app updates were installed later that morning in response to the problem; neither changed the behaviour.

Request: the known-good bundle is demonstrated working on Intel x86 as recently as 18 Aug 15:49 AEST. Could it be republished for x64, or a mechanism provided to pin the previous bundle, while the known-bad one is investigated? Deleting the local bundle is not a workaround — the app re-downloads the broken one. There is currently no workaround on the desktop app for Intel Macs.

On the duplicate label: it was applied automatically, with no target issue linked under Relationships. No prior report names this bundle hash, and the Windows-on-ARM reports hang at a different step (add_plan9_shares). Could the label be reviewed?

Suggested labels: area:cowork, area:desktop, platform:macos, bug

Note: after every failure the app runs a network diagnostics dump and surfaces VPN-related messaging. This is misleading — the failing step is host-local vsock and PF_VSOCK registers fine inside the guest.