›_ Claude Code Issues
Claude Code Issues / #77483

[BUG] Cowork VM fails to start in 90% of attempts (54/60) — three distinct failure modes — Windows 10

Open 💬 0 comments Opened Jul 14, 2026 by xvmaster13

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?

Environment

  • OS: Windows 10 Home, version 22H2, OS Build 19045.6466
  • Claude Desktop package version: 1.20186.9.0
  • Cowork VM bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a

What's wrong
Cowork fails to start with "VM connection timeout after 60 seconds", but the
host log shows the guest actually finishes booting and becomes reachable
shortly AFTER the host has already declared the timeout and surfaced the
error to the user. This suggests the fixed 60s timeout is too tight for some
legitimate (if slightly slow) boot sequences, rather than indicating a
broken VM or corrupted bundle.

Log evidence (cowork_vm_node.log, host side)
add_plan9_shares completed (132ms)
Still waiting for guest connection... 10182ms elapsed, 21 polls
Still waiting for guest connection... 20404ms elapsed, 41 polls
Still waiting for guest connection... 30572ms elapsed, 61 polls
Still waiting for guest connection... 41052ms elapsed, 81 polls
Still waiting for guest connection... 51259ms elapsed, 101 polls
[error] Connection timeout, last completed step: add_plan9_shares
Dispatching startup error: VM connection timeout after 60 seconds
Startup failed: Error: VM connection timeout after 60 seconds
Skipping auto-reinstall (already attempted once)
[VM] Network status: CONNECTED <-- ~23s AFTER the error above
[VM] API reachability: REACHABLE <-- ~36s AFTER the error above

Observation
All host-side startup steps complete without error (download_and_sdk_prepare,
load_swift_api, vm_boot, add_plan9_shares). The guest simply needs slightly
more than 60 seconds to complete its own boot and establish the RPC
connection back to the host. Excluding the VM bundle folder from Windows
Defender real-time scanning reduces time spent on copy/configure steps, but
the margin against the 60s deadline still appears thin on this machine.

Also observed (possibly related, separate symptom)
Before this startup attempt, there was a sustained burst of:
Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service
for several minutes, suggesting CoworkVMService was transiently unreachable
— this correlated with the machine waking from sleep.

Request
Either increase the timeout threshold, or have the host retry the guest
connection check once (or poll a bit longer) before surfacing a hard error,
since in this case the connection completes correctly just past the current
deadline.

Related issues
#27801, #42784, #45883, #48370, #65128, #67066 — same error message, but
none of those threads show the host log confirming the guest DOES connect
shortly after the timeout is declared. Posting this as it may narrow the
root cause to a timing/race issue rather than bundle corruption.

Note: this specific description covers the 60s-timeout variant because it's
the one with clear host-log evidence (guest connecting ~23s after the
declared timeout). However, across the full session log there were 60
total startup attempts: only 6 succeeded. The 54 failures break down into
three distinct error types:

  • "VM service not running. The service failed to start." — 45 occurrences,

concentrated in a ~13-hour window (2026-07-12 22:55 to 2026-07-14 11:42)

  • "VM connection timeout after 60 seconds" — 6 occurrences (this report's

focus)

  • "request timed out after 30s" — 3 occurrences (a third, separate error

not analyzed in this report)
These may be three distinct root causes; this report focuses on the
connection-timeout variant since it's the one I could analyze in detail
with host-log evidence.

What Should Happen?

Cowork should successfully start the workspace. Since the host log shows
the guest VM does complete its boot and becomes reachable (Network status:
CONNECTED, API reachability: REACHABLE) just ~23 seconds after the current
60-second timeout is hit, one of the following should happen instead of a
hard failure:

  1. The host's connection-timeout threshold should be increased (or made

adaptive to the machine's actual boot time), so a guest that connects
at ~83s isn't treated as a failure, or

  1. The host should retry/poll a bit longer before surfacing an error to

the user, since in this case the connection completes correctly shortly
after the current deadline.

Either way, Cowork should not show a hard failure and skip auto-reinstall
when the guest is, in fact, successfully booting — just slightly slower
than the fixed window allows.

Additionally, the more frequent "VM service not running" failure (45
occurrences) should not require the user to manually restart the machine
or the app repeatedly — ideally CoworkVMService should either auto-recover
or the host should surface a clearer diagnostic than a generic
"service failed to start" message, since this error gives no indication
of why the Windows service itself isn't starting.

Error Messages/Logs

=== Host log (cowork_vm_node.log) — the failed attempt with detailed timing ===
[VM:steps] add_plan9_shares completed (132ms)
[VM:start] Still waiting for guest connection... 10182ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20404ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30572ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 41052ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 51259ms elapsed, 101 polls
[error] [VM:start] Connection timeout, last completed step: add_plan9_shares
Dispatching startup error: VM connection timeout after 60 seconds
[error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
[VM:start] Skipping auto-reinstall (already attempted once)
[VM] Network status: CONNECTED       <-- ~23s AFTER the error above
[VM] API reachability: REACHABLE     <-- ~36s AFTER the error above

=== Error breakdown across full log (60 total startup attempts) ===
VM service not running. The service failed to start.  — 45 occurrences
VM connection timeout after 60 seconds                — 6 occurrences
request timed out after 30s                            — 3 occurrences
Successful startups (API reachability: REACHABLE)      — 6 occurrences

=== Related symptom before this attempt ===
Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service
(sustained for several minutes, correlating with machine waking from sleep)

Steps to Reproduce

This is an intermittent timing issue, not a guaranteed 100%-reproducible
sequence — it depends on how close the guest's boot time is to the 60s
threshold at the moment Cowork is launched.

  1. Open Claude Desktop on Windows.
  2. Switch to the Cowork tab (or otherwise trigger a VM start).
  3. Wait for the VM startup sequence to run.

In most cases on this machine, the guest boot has been landing close to or
slightly past the 60-second host timeout, particularly:

  • After the machine wakes from sleep rather than a cold boot.
  • When the VM bundle folder is not excluded from real-time antivirus

scanning (Windows Defender), which added measurable time to the
download_and_sdk_prepare and Windows VM service configuration steps.

I don't have a deterministic single sequence that reproduces this on
demand every time — the host log evidence above is from one specific
failed attempt where the timing was captured in detail.

Additional context: across the full session log there were 60 total
startup attempts — 54 failed, 6 succeeded. The failures split into three
error types: 45 "VM service not running", 6 "VM connection timeout after
60 seconds" (the focus of this report), and 3 "request timed out after
30s" (a third, distinct error not covered here). This report documents the
connection-timeout variant in detail since it has clear host-log evidence,
but "VM service not running" is the dominant failure mode by far on this
machine.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A - not using Claude Code CLI, this is a Claude Desktop/Cowork issue (Claude Desktop version 1.20186.9.0, see Environment section above)

Platform

Claude Pro subscription via Claude Desktop — not applicable to
Anthropic API/Bedrock/Vertex AI, hence "Other" selected above.

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Antivirus exclusions were added for the VM bundle folder
(C:\Users\...\AppData\Roaming\Claude\vm_bundles) and the WindowsApps
install folder in Windows Defender after these logs were captured, as a
mitigation attempt. This may reduce the frequency of the timing-related
60s timeout, but does not appear related to the "VM service not running"
failures, which are the majority of the 54 failed attempts.

View original on GitHub ↗