[BUG] Cowork VM: guest kernel boots but init hangs at 1.5s — "Direct-boot artifacts not present" false negative forces broken EFI/GRUB fallback (v1.32352.1, macOS 26.5.2 Intel)

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?

Related to #87617 — same failure signature on a different machine, filed the same day. Independent confirmation: identical app version (1.32352.1), identical bundle hash (2a762adfc2eea13eca0d113a2e6452ff00ae3f62), Intel Mac, same Direct-boot artifacts not present line, same guest stall point. That report lists the regression status as "I don't know" and leaves Last Working Version blank; this report supplies both — the failure began immediately after the auto-update to 1.32352.1, and 1.8555.0 is a confirmed-working build. Filing separately for the root-cause analysis below; happy for maintainers to consolidate.

---

After Claude Desktop auto-updated on Aug 18, 2026, the Cowork workspace VM stopped starting. Every attempt ends in VM connection timeout after 60 seconds.

The VM boots at the hypervisor level and the guest kernel initializes correctly, but the guest console goes silent 1.497 seconds into boot, immediately after Run /init as init process. coworkd never starts, so the host's guest_vsock_connect step waits the full 60 seconds and times out. This repeats indefinitely.

The likely trigger is visible one line before boot in cowork_vm_swift.log:

[VM] Direct-boot artifacts not present in bundle; using EFI (GRUB) boot

This is a false negative. The direct-boot artifacts ARE present in the bundle, freshly downloaded and decompressed:

-rw-------@ 1 user  staff    27M Aug 18 15:23 initrd
-rw-------@ 1 user  staff    14M Aug 18 15:23 vmlinuz

The app fails to recognize its own artifacts, silently falls back to the EFI/GRUB boot path, and that path hangs in guest init. This looks like an app-version/bundle-version mismatch introduced by the update: the app requests a bundle it then cannot use for direct boot. Notably, #87617 shows the same Direct-boot artifacts not present line on a different machine with the same bundle hash, which suggests the bundle being served does not contain what 1.32352.1 expects.

Why this is not the already-reported causes

Each existing explanation was ruled out with evidence:

| Suspected cause | Ruled out by |
|---|---|
| Corrupted VM image (#24070) | Bundle fully deleted and re-downloaded. rootfs.img is a complete 10 GB, rootfs.img.zst 1.2 GB. Fresh bundle fails identically. |
| Disk space / failed extraction | 840 Gi available, 2% capacity used. |
| Missing com.apple.vm.networking entitlement (#66870) | Entitlement is indeed absent (only com.apple.security.virtualization present), but irrelevant here — the app runs networkMode=gvisor user-mode networking, which does not require it. gvisor reports success: usernet: network stack started successfully. |
| VPN interference | utun0–utun3 exist, but gvisor usernet does not route through them, and the guest never reaches userspace networking anyway. |
| Host-side vsock blocked | Failure is guest-side. The host polls correctly; nothing in the guest ever answers. |

Additional findings

1. .auto_reinstall_attempted permanently disables self-repair. Once written, this marker in the bundle directory causes every subsequent failure to log Skipping auto-reinstall (already attempted once). It is never cleared on success or on app update, and it survives app reinstall. One transient failure costs the user automatic recovery forever.

2. App reinstall does not replace the VM bundle. Reinstalling from the DMG leaves vm_bundles/ untouched — still the behaviour reported in #24070. Users following the in-app guidance never replace the actual images.

3. Machine identity is reused across retries. Before manual bundle deletion, the VM instance ID was byte-identical on every retry (27b297e4-...) because machineIdentifier, efivars.fd, and sessiondata.img persist. Every retry reproduces the same failure, and there is no UI path to force a new identity.

4. Failed VMs do not stop cleanly. Each retry logs Timeout waiting for VM to stop (state: 1), proceeding with cleanup after a full 60 seconds, so every cycle costs ~120 seconds and leaves resources behind. #87617 shows stop_existing_vm completed (60201ms) — the same behaviour.

5. No guest-side diagnostics past kernel handoff. When init hangs there is no captured output explaining why. The kernel console stops at clocksource and nothing indicates what init was waiting on.

Impact

Roughly four hours were spent on restarts, OS reboots, repeated in-app workspace reinstalls, a full app delete-and-reinstall, and manual bundle deletion — none of which could have worked, because the error message and the in-app repair action both point away from the actual cause.

What Should Happen?

The Cowork workspace should start and the bash sandbox should become available.

Specifically:

1. Direct-boot artifact detection should not produce a false negative. vmlinuz and initrd are present and decompressed in the bundle, yet the app reports them missing and degrades to an EFI/GRUB path that hangs. If the check fails, it should log what it looked for and why, rather than silently falling back to a path that does not work.
2. App/bundle version compatibility should be validated before boot, with a clear error, instead of a silent fallback.
3. .auto_reinstall_attempted should be cleared on successful boot and on app update, so one transient failure does not permanently disable self-repair.
4. App reinstall should refresh the VM bundle, or the UI should expose a real "Reset workspace" action that deletes and re-downloads it. Users currently cannot replace a bad image without knowing the on-disk path.
5. Guest init console output should be captured past kernel handoff so hangs like this are diagnosable without manual log archaeology.
6. The error message should not misdirect. "VM connection timeout" plus a VPN hint sends users to restarts, reinstalls, and network debugging when the actual failure is guest init.

Error Messages/Logs

=== HOST: cowork_vm_node.log (identical on every attempt) ===
[VM:start] Beginning startup, bundlePath=.../vm_bundles/claudevm.bundle
[VM:start] Bundle version: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62
[VM:start] VM instance ID: 27b297e4-7973-4948-b0bc-2bb165ab2128
[VM:start] memory=4GB tier=flat
[VM:start] Still waiting for guest connection... 10013ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20079ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30096ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 40110ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 50119ms elapsed, 101 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)

=== HOST: cowork_vm_swift.log ===
[VM] Direct-boot artifacts not present in bundle; using EFI (GRUB) boot
[VM] Found smol-bin image at /Applications/Claude.app/Contents/Resources/smol-bin.x64.img
[VM] Added smol-bin.img as read-only virtio-blk device
[VM] Using gvisor user-mode networking
[VM] Created gvisor network socket pair (vm=108, go=134)
[VM] Gvisor usernet started
[VM] Console device attached: port 0 (coworkd/hvc0), port 1 (kernel boot/hvc1)
[VM] Configuration created:
[VM]   - CPUs: 4
[VM]   - Memory: 4GB
[VM]   - Boot: EFI (GRUB)
[VM] VM startup step: vm_boot started
[VM] Linux VM started successfully
[VM] VM startup step: vm_boot completed
[VM] VM startup step: guest_vsock_connect started
    <-- no further output; 60s timeout follows

(also seen on every retry cycle:)
[VM] Stopping VM (isAppQuit: false)...
[VM] VM requestStop() completed
[VM] Timeout waiting for VM to stop (state: 1), proceeding with cleanup

=== GUEST: coworkd.log (console output ENDS here and never resumes) ===
[KERNEL] [ 0.969754] Run /init as init process
[KERNEL] [ 1.040008] NET: Registered PF_VSOCK protocol family
[KERNEL] [ 1.041261] virtio_net virtio0 enp0s1: renamed from eth0
[KERNEL] [ 1.419405] raid6: using algorithm avx512x4 gen() 49746 MB/s
[KERNEL] [ 1.436457] raid6: using avx512x2 recovery algorithm
[KERNEL] [ 1.438033] async_tx: api initialized (async)
[KERNEL] [ 1.496997] tsc: Refined TSC clocksource calibration: 3491.250 MHz
[KERNEL] [ 1.498587] clocksource: Switched to clocksource tsc
    <-- END OF LOG. No init output, no service startup, no coworkd.

=== GUEST NETWORK: vzgvisor.log (healthy; waiting for a guest that never arrives) ===
usernet: starting with sockFD=134
usernet: vmMAC=ca:e6:82:e8:ef:a2
usernet: virtual network created successfully
usernet: network stack started successfully
usernet: calling AcceptBess...

=== ENVIRONMENT ===
Claude Desktop: 1.32352.1
macOS: 26.5.2 (Build 25F84)
Architecture: x86_64 / Intel (smol-bin.x64.img, avx512, TSC 3491.250 MHz)
Disk: 840 Gi free of 932 Gi
Entitlements: com.apple.security.virtualization present; com.apple.vm.networking absent
Bundle contents after fresh re-download:
  rootfs.img      10G
  rootfs.img.zst  1.2G
  initrd          27M
  vmlinuz         14M
  sessiondata.img 4.0M
  efivars.fd      128K

Steps to Reproduce

1. Have a working Cowork workspace on Claude Desktop (Intel Mac, macOS 26.5.2)
2. Allow Claude Desktop to auto-update to v1.32352.1 (Aug 18, 2026)
3. Trigger any tool requiring the bash sandbox
4. Observe VM connection timeout after 60 seconds, repeating indefinitely
5. Confirm that NONE of the following resolve it:

• Restarting Claude Desktop (5+ times)
• Restarting macOS
• In-app "reinstall workspace" (many times)
• Deleting ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle and letting it re-download
• Deleting /Applications/Claude.app and reinstalling from a freshly downloaded DMG

Note: after a full app reinstall AND a full bundle delete (both halves fresh), the failure is identical and .auto_reinstall_attempted reappears in the new bundle — the app auto-repaired, failed, and re-disabled self-repair.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.8555.0 (Claude Desktop, May 21 2026) — confirmed working build; exact immediately-prior version unknown

Claude Code Version

Claude Desktop 1.32352.1 (this is a Claude Desktop / Cowork issue, not Claude Code CLI)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_