### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? Cowork's local VM worked reliably on my Intel Mac for two weeks, then broke on 2026-08-18 when the VM bundle was switched from 6d1538ba… to 2a762adf…. The

[BUG] Cowork VM regression on Intel Mac (x86_64): guest never connects after bundle 2a762ad rollout — same app version works on arm64

Status Closed — duplicate

Reported on v2.1.229

Maintainer reply None cached

Activity 3 comments · opened Aug 18, 2026 · closed Aug 20, 2026

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?

Cowork's local VM worked reliably on my Intel Mac for two weeks, then broke on 2026-08-18 when the VM bundle was switched from 6d1538ba… to 2a762adf…. The VM boots, but the guest never establishes the vsock connection, and startup fails with VM connection timeout after 60 seconds.

I have a second machine on Apple Silicon running the same app version (1.32352.1) and the same bundle version tag (2a762adf…) which is completely unaffected. Under that same bundle tag the two machines are served different image files, and the x86_64 set does not produce a guest that connects.

I'm aware Intel Mac is not an officially supported Cowork platform (#20787). Filing this anyway because an x86_64 image set is actively being served, it demonstrably worked until this rollout, and the failure is a clean regression with a precise timestamp.

What Should Happen?

guest_vsock_connect should complete and the workspace should start, as it did on bundle 6d1538ba… up to 2026-08-16.

Error Messages/Logs

From ~/Library/Logs/Claude/cowork_vm_node.log:

15:48:40 [VM:steps] download_and_sdk_prepare completed (120188ms) 15:48:41 [VM:steps] vm_boot started 15:48:41 [VM:steps] vm_boot completed (383ms) 15:48:41 [VM:steps] guest_vsock_connect started 15:48:51 [VM:start] Still waiting for guest connection... 10106ms elapsed, 21 polls 15:49:01 [VM:start] Still waiting for guest connection... 20125ms elapsed, 41 polls 15:49:11 [VM:start] Still waiting for guest connection... 30140ms elapsed, 61 polls 15:49:21 [VM:start] Still waiting for guest connection... 40155ms elapsed, 81 polls 15:49:31 [VM:start] Still waiting for guest connection... 50165ms elapsed, 101 polls 15:49:41 [error] [VM:start] Connection timeout, last completed step: vm_boot 15:49:42 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds 15:49:42 [VM:start] Skipping auto-reinstall (already attempted once)

From ~/Library/Logs/Claude/coworkd.log — the guest kernel boots but the log ends during storage/crypto init and nothing follows:

[KERNEL] raid6: using algorithm avx2x2 gen() 16980 MB/s [KERNEL] raid6: .... xor() 14754 MB/s, rmw enabled async_tx: api initialized (async) xor: automatically using best checksumming function avx

Also logged during the failure path (possibly a separate minor bug):

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

Steps to Reproduce

On an Intel Mac (x86_64), run Claude Desktop 1.32352.1
Open Cowork and start a workspace
The VM boots (vm_boot completed), then hangs at guest_vsock_connect
After 60 seconds it fails with VM connection timeout after 60 seconds

Happens on every start, 100% reproducible since 2026-08-18.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

VM bundle 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a (last successful start 2026-08-16 18:25)

Claude Code Version

Claude Desktop 1.32352.1 (Cowork), claude-code-vm SDK 2.1.229

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="115:1-115:15;3993-4007">Environment</h2>

</div>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="127:1-127:40;4388-4427">Timeline (from <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork_vm_node.log</code>)</h2>

<div role="group" aria-label="Code" tabindex="0" data-sourcepos="129:1-138:4;4429-4935" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">2026-08-02 12:36 Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
2026-08-13 10:51 macOS updated to 26.6.2 (Cowork still worked after this)
2026-08-14 09:51 guest_vsock_connect completed (0ms) OK
2026-08-15 13:01 guest_vsock_connect completed (6451ms) OK
2026-08-16 18:25 guest_vsock_connect completed (8285ms) OK
2026-08-18 04:36 Bundle version: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62
2026-08-18 08:17 Claude.app updated to 1.32352.1
2026-08-18 onward every start fails</code></pre></div></div>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="140:1-142:65;4937-5160">Note the degradation on the old bundle before it broke: 0ms → 6451ms → 8285ms.
Also note macOS was updated on 08-13, five days before the failure and followed
by three successful starts, so the OS update is not the trigger.</p>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="144:1-144:50;5162-5211">Different image sets under the same bundle tag</h2>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="146:1-146:91;5213-5303"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">shasum -a 256</code> of <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/*.zst</code></p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="148:1-148:25;5305-5329">Apple Silicon (working):</p>

<div role="group" aria-label="Code" tabindex="0" data-sourcepos="149:1-155:4;5330-5695" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">d730ff659e70f4d45da520694bbe62f4ee23af2534549ed8fed92c1463704ae7 initrd-micro.zst
9d3a8f648efdb7006de4d20f5775cbc8532459a6be5519fbed27e606a5b105ec initrd.zst
cf117e79e5c3be5471807ed0f8f524c0f54b2a83574551e809ece77409efb31d rootfs.img.zst
f380613cca6621662cfa10c501ff38dff5769526578db5e57b3cbe2b0e2fbafb vmlinuz.zst
vmlinuz decompressed: 59,074,952 bytes</code></pre></div></div>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="157:1-157:16;5697-5712">Intel (broken):</p>

<div role="group" aria-label="Code" tabindex="0" data-sourcepos="158:1-164:4;5713-6034" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">(no initrd-micro.zst is served at all)
6bf448d34e72d8c0bbda9c32eb3589e2b602b6c780df6880212e2cf7a778fa34 initrd.zst
8ea6798faa09b15ecf66acba547b14e1c60dfe8980e2f7cb9faedaccf4c4c3ae rootfs.img.zst
8c74da17c86a7efad89b43fd0d11235dc257b13a7f56b2fdd3677d3fe3562a3e vmlinuz.zst
vmlinuz decompressed: 15,014,280 bytes</code></pre></div></div>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="166:1-169:16;6036-6283">The size difference is consistent with arm64 <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Image</code> vs x86_64 self-compressed
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">bzImage</code>, so the per-arch split itself is expected. What matters is that the
x86_64 set never produces a guest that connects, and that it ships without
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">initrd-micro</code>.</p>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="171:1-171:41;6285-6325">What I tried (all failed identically)</h2>

<ul dir="ltr" class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3 print:block print:space-y-1" data-sourcepos="173:1-179:34;6327-6751">
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="173:1-173:41;6327-6367">Full quit and relaunch, multiple times</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="174:1-175:58;6368-6495">Deleted the decompressed images (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">rootfs.img</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">vmlinuz</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">initrd</code>,
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">sessiondata.img</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">efivars.fd</code>) to force re-extraction</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="176:1-178:75;6496-6717">Deleted the cached <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">.zst</code> archives to force a full re-download — the
re-downloaded archives were <strong>byte-identical</strong> (same SHA-256) to the ones
removed, confirming this is the image being served, not local corruption</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="179:1-179:34;6718-6751">Verified 327 GB free disk space</li>
</ul>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="181:1-181:12;6753-6764">Requests</h2>

<ol dir="ltr" class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3 print:block print:space-y-1" data-sourcepos="183:1-191:25;6766-7287">
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="183:1-185:12;6766-6928">Can the x86_64 image set for bundle <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">2a762adf…</code> be checked — specifically
whether its guest agent starts, and whether the missing <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">initrd-micro</code>
matters?</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="186:1-187:25;6929-7029">Is there a supported way to pin or roll back to bundle <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">6d1538ba…</code> while
this is investigated?</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="188:1-191:25;7030-7287">If Intel Mac Cowork is being wound down rather than fixed, an explicit
message at startup would be much better than a 60-second timeout followed by
network diagnostics that point nowhere — vsock is not IP networking and the
host network is fine.</li>
</ol>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="193:1-193:20;7289-7308">Possibly related</h2>

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗