[BUG] Cowork: VM boots but guest_vsock_connect never completes on Intel Mac — "Direct-boot artifacts not present in bundle", 60s timeout

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?

The Cowork Linux sandbox (mcp__workspace__bash) fails to start. Every call returns Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds).

The kernel boots fine. The guest agent (coworkd) never starts, so the host blocks at guest_vsock_connect and times out. This is a regression: the VM was fully operational on 1.32352.0 and has failed on every attempt since the app auto-updated to 1.32352.1.

Related but distinct: #66803, #76374, #42784, #60631, #66870. Every existing macOS report is Apple Silicon and none pins a known-good version. This is Intel x86_64 and isolates the regression to a single point release.

The regression window

| Timestamp (MDT) | Event | Source |
|---|---|---|
| 2026-08-17 18:21 | Probe written: {"key":"1.32352.0\|25.5.0\|x64","supported":true} | vm-support-probe.json |
| 2026-08-17 18:25:44 | VM fully operational — virtiofs mounts, cgroups, bash spawning curl | coworkd.log |
| 2026-08-18 00:14 | /Applications/Claude.app replaced: 1.32352.0 → 1.32352.1 | app bundle mtime |
| 2026-08-18 08:46 – 10:51 | Eight startup attempts, all fail identically | cowork_vm_swift.log |
| 2026-08-18 10:37 | Probe rewritten: {"key":"1.32352.1\|25.5.0\|x64","supported":true} | vm-support-probe.json |

Last known-good: 1.32352.0. Every failure: 1.32352.1.

The proximate defect: direct-boot artifacts exist but are reported absent

After a full clean re-provision, the bundle contains both direct-boot artifacts:

| Size | Written | File |
|---|---|---|
| 28165330 | Aug 18 10:38 | initrd |
| 15014280 | Aug 18 10:38 | vmlinuz |
| 10737418240 | Aug 18 10:49 | rootfs.img |
| 40 | Aug 18 10:38 | .vmlinuz.origin |
| 40 | Aug 18 10:38 | .initrd.origin |
| 0 | Aug 18 10:36 | .auto_reinstall_attempted |

vmlinuz and initrd were decompressed at 10:38. At 10:49:22, eleven minutes later, the supervisor still logs Direct-boot artifacts not present in bundle; using EFI (GRUB) boot.

The artifacts are present and the app refuses to recognize them. This is a validation failure, not a missing-file condition. The 40-byte .origin sidecars are consistent with SHA-1 content hashes; my hypothesis is that 1.32352.1 validates against these and rejects artifacts 1.32352.0 accepted.

Consequence: the supervisor falls back to booting smol-bin.x64.img (a 24 MB helper image), whose /init hangs. That 24 MB image is the only block device the guest kernel enumerates — neither rootfs.img nor sessiondata.img appears in guest device enumeration, despite both being listed in the host-side VM configuration.

The self-repair path is also broken

.auto_reinstall_attempted exists at 0 bytes. The app detected the condition, attempted an automatic reinstall, and that path failed too. There is no way for an affected user to break the loop.

What Should Happen?

guest_vsock_connect should complete and coworkd should start inside the guest, as it did on 1.32352.0.

Failing that, the supervisor should not report Direct-boot artifacts not present in bundle when vmlinuz and initrd are present in that bundle. If those artifacts are being rejected by a hash or version check, the log should say so — the current message sends users chasing a missing-file problem that does not exist, and the documented "delete the bundle and let it rebuild" remedy cannot fix it.

Error Messages/Logs

=== 1. HOST SUPERVISOR STALLS AT guest_vsock_connect ===
~/Library/Logs/Claude/cowork_vm_swift.log

[VM] 2026-08-18 10:49:22 [info] Using bundle at <app-support>/vm_bundles/claudevm.bundle
[VM] 2026-08-18 10:49:22 [info] Direct-boot artifacts not present in bundle; using EFI (GRUB) boot
[VM] 2026-08-18 10:49:22 [info] Found smol-bin image at /Applications/Claude.app/Contents/Resources/smol-bin.x64.img
[VM] 2026-08-18 10:49:22 [info] Added smol-bin.img as read-only virtio-blk device
[VM] 2026-08-18 10:49:22 [info] Using gvisor user-mode networking
[VM] 2026-08-18 10:49:22 [info] Gvisor usernet started
[VM] 2026-08-18 10:49:22 [info] Console device attached: port 0 (coworkd/hvc0), port 1 (kernel boot/hvc1)
[VM] 2026-08-18 10:49:22 [info]   - CPUs: 4
[VM] 2026-08-18 10:49:22 [info]   - Memory: 4GB
[VM] 2026-08-18 10:49:22 [info]   - Boot: EFI (GRUB)
[VM] 2026-08-18 10:49:22 [info]   - Rootfs: <bundle>/rootfs.img
[VM] 2026-08-18 10:49:22 [info]   - Session data: <bundle>/sessiondata.img
[VM] 2026-08-18 10:49:22 [info] VM startup step: vm_boot started
[VM] 2026-08-18 10:49:22 [info] Linux VM started successfully
[VM] 2026-08-18 10:49:22 [info] VM startup step: vm_boot completed
[VM] 2026-08-18 10:49:22 [info] VM startup step: guest_vsock_connect started
<-- NO FURTHER OUTPUT. 60s timeout.

Identical at 08:46:35, 08:48:23, 10:09:59, 10:12:35, 10:15:03, 10:18:27, 10:47:18, 10:49:22.
Teardown also hangs every time:
[VM] 2026-08-18 10:49:22 [warn] Timeout waiting for VM to stop (state: 1), proceeding with cleanup


=== 2. HOST NETWORKING COMES UP CLEAN, THEN BLOCKS ON ACCEPT ===
~/Library/Logs/Claude/vzgvisor.log

level=info msg="usernet: virtual network created successfully"
level=info msg="usernet: net.Conn created from socket, type=*net.UnixConn"
level=info msg="usernet: network stack started successfully"
level=info msg="usernet: calling AcceptBess..."
<-- LAST LINE. Blocks indefinitely because no guest ever attaches.

This rules out the missing com.apple.vm.networking theory from #66870 -- the stack
is created successfully, and gvisor user-mode networking does not need vmnet.


=== 3. GUEST KERNEL BOOTS, THEN GOES SILENT AT ~1.5s ===
~/Library/Logs/Claude/coworkd.log (guest console, hvc0/hvc1)

[    0.576829] virtio_blk virtio1: [vda] 47104 512-byte logical blocks (24.1 MB/23.0 MiB)
[    0.824606] Freeing initrd memory: 27508K
[    0.995842] Run /init as init process
[    1.066259] NET: Registered PF_VSOCK protocol family
[    1.070993] virtio_net virtio0 enp0s1: renamed from eth0
[    1.412368] async_tx: api initialized (async)
[    1.496112] clocksource: Switched to clocksource tsc
<-- GUEST CONSOLE ENDS HERE. No root pivot, no systemd handoff, no coworkd.

Note: vda at 24.1 MB is smol-bin.x64.img. It is the ONLY block device enumerated.
rootfs.img (10 GiB) and sessiondata.img never appear in the guest.


=== 4. PROOF THE VM WORKED ON 1.32352.0 ===
~/Library/Logs/Claude/coworkd.log (head of file), paths redacted

2026/08/17 18:25:44 [coworkd] mounted <workspace-folder> at /sessions/<name>/mnt/<folder> (mode=rw)
2026/08/17 18:25:44 [coworkd] mounted <outputs> at /sessions/<name>/mnt/outputs (mode=rw)
2026/08/17 18:25:44 [process:oneshot-<uuid>] spawn: name=<user> cmd=bash args=[-c cd /tmp && curl -sL ...]
2026/08/17 18:25:44 [cgroup] initialized subtree at /sys/fs/cgroup/coworkd
2026/08/17 18:25:44 [process:oneshot-<uuid>] started PID 23525
2026/08/17 18:25:44 [process:oneshot-<uuid>] direct child exited: code=0 signal=<nil>

Full guest: virtiofs mounts, user namespacing, cgroup creation, process spawn, clean exit.


=== 5. DIRECT-BOOT ARTIFACTS PRESENT ON DISK ===
ls -la <app-support>/vm_bundles/claudevm.bundle/

    28165330 Aug 18 10:38  initrd
    15014280 Aug 18 10:38  vmlinuz
    27816400 Aug 18 10:35  initrd.zst
    14761727 Aug 18 10:35  vmlinuz.zst
  1286740082 Aug 18 10:35  rootfs.img.zst
 10737418240 Aug 18 10:49  rootfs.img
     4194304 Aug 18 10:35  sessiondata.img
      131072 Aug 18 10:49  efivars.fd
          40 Aug 18 10:38  .vmlinuz.origin
          40 Aug 18 10:38  .initrd.origin
          40 Aug 18 10:38  .rootfs.img.origin
           0 Aug 18 10:36  .auto_reinstall_attempted

vmlinuz and initrd written 10:38. Supervisor still says "not present" at 10:49:22.

Steps to Reproduce

1. Intel Mac (x86_64), macOS 26.5.2, Claude Desktop 1.32352.1, Cowork session with a connected workspace folder.
2. Ask Claude to run any shell command, e.g. echo test.
3. Observe the 60-second timeout: Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds).
4. tail ~/Library/Logs/Claude/cowork_vm_swift.log — startup stalls at guest_vsock_connect started and produces no further output.
5. tail ~/Library/Logs/Claude/coworkd.log — guest console stops ~1.5s after Run /init as init process.
6. Quit the app fully. Move ~/Library/Application Support/Claude/vm_bundles/ aside. Relaunch. The bundle re-provisions completely (~11 GB, rootfs.img decompresses to exactly 10 GiB) and fails identically.
7. ls -la ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/ — vmlinuz and initrd are both present, yet step 4's log still reports Direct-boot artifacts not present in bundle.

Reproduces on every Cowork session, new and existing. Does not reproduce on 1.32352.0.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.32352.0 (Claude Desktop / Cowork) — confirmed working 2026-08-17 18:25:44 MDT

Claude Code Version

N/A — this is Claude Desktop (Cowork) 1.32352.1, not the Claude Code CLI

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

• macOS 26.5.2, build 25F84
• Intel x86_64 (uname -m = x86_64; guest reports TSC 2400 MHz, intel_pstate, AVX2)
• Claude Desktop 1.32352.1, Electron 42.9.2
• VM config: memoryGB=4, cpuCount=auto (4), networkMode=gvisor, Boot: EFI (GRUB)
• Not affected: Read/Write/Edit/Glob/Grep file tools, MCP connectors, web fetch. Only mcp__workspace__bash.

What I already tried (~24 hours, none of it worked)

Listed so triage does not send me back through the standard checklist. Every item was performed and verified.

1. Reinstalled Claude Desktop, many times. No effect. The installer does not replace ~/Library/Application Support/Claude/vm_bundles/, so a bad bundle survives every reinstall.
2. Full quit (Cmd+Q) plus process sweep. pgrep -fl Claude, killed leftovers, relaunched. No effect.
3. Full system reboot, to clear any wedged Hypervisor.framework state after the repeated Timeout waiting for VM to stop events. No effect.
4. Quarantined vm-support-probe.json (2026-08-17 18:21). The app rewrote it. This coincided with the one brief period the VM worked again at 18:25:44 — but that was still on 1.32352.0, and it has not been reproducible since the 1.32352.1 update.
5. Quarantined vm_bundles/ and let the app re-provision from scratch — twice. Both rebuilds completed fully (~11 GB, rootfs.img decompressed to exactly 10 GiB, vmlinuz and initrd both written). Both fail identically. This is the step every troubleshooting guide calls the nuclear option; it does not work here.
6. Verified free disk: 98 GiB available on a 932 GiB volume (11% used).
7. Verified code signature and quarantine state: codesign -v --deep --strict /Applications/Claude.app clean; no com.apple.quarantine xattr.
8. Verified entitlements: com.apple.security.virtualization and com.apple.security.cs.allow-jit both present.
9. Tested the subprocess helper directly: Contents/Helpers/disclaimer /usr/bin/pgrep -fl Claude returns exit 0. (It threw exit 1 inside networkDiagnostics earlier; it is not the cause.)
10. Audited for security software: systemextensionsctl list shows no EDR or security extensions — only Samsung DriverKit and Adobe Creative Cloud agents. No VPN active.
11. Confirmed both architecture images ship: smol-bin.arm64.img and smol-bin.x64.img, 24117248 bytes each, Aug 18 00:14.
12. Collected the full unified log (log show --predicate 'process CONTAINS "Claude"') plus every file in ~/Library/Logs/Claude/. That is the source of the version correlation above.
13. Tried both new and existing Cowork sessions. Identical failure in all.

The only untried remediation is downgrading to 1.32352.0, which is not possible because that build is not available for download.

Ruled out — please don't ask me to re-check these

| Suspected cause | Status |
|---|---|
| Missing x64 architecture artifacts | Ruled out — both smol-bin images ship, identical sizes |
| Disk space | Ruled out — 98 GiB free |
| Corrupt VM bundle | Ruled out — re-provisioned twice from scratch, identical failure |
| Reinstalling the app | Ruled out — cannot touch vm_bundles/ |
| Code signing / Gatekeeper | Ruled out — codesign clean, no quarantine xattr |
| Missing com.apple.vm.networking (#66870) | Ruled out — gvisor usernet starts successfully |
| Helper subprocess spawning | Ruled out — disclaimer exits 0 |
| Security software / EDR / VPN | Ruled out — none present |
| VM support probe | Ruled out — reports "supported":true on both versions |

Requests

1. Please confirm whether 1.32352.1 changed validation of bundle direct-boot artifacts, and whether a 1.32352.0-provisioned bundle can be migrated.
2. Please make the 1.32352.0 macOS build available for download. There is currently no rollback path and no local workaround for affected users.
3. Please fix the log message. Direct-boot artifacts not present in bundle is emitted while those artifacts are present, which actively misdirects troubleshooting.

I can supply full unredacted logs privately on request.