[BUG] Cowork — VM service not running on Windows 11 (fresh repro + workaround; extends closed #54891 / #61559 cluster)

Additional evidence — cowork_vm_node.log timeline

Confirmed via local log file %APPDATA%\Claude\logs\cowork_vm_node.log.

Failure window

• Start: 2026-06-01 17:07:09
• End (last failure entry): 2026-06-01 21:58:06
• Duration: ~5 hours of continuous failure
• Failure count: 17,135 lines (1 per second retry loop)

Failure signature (repeated every second)


[warn] [vm-client] Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service


→ Named pipe \\.\pipe\cowork-vm-service does not exist = CoworkVMService is not running at all (no listener), so client cannot connect. This corroborates the user-facing error message ("VM service not running") at the pipe-level.

Recovery transition

• First successful connect: 2026-06-01 22:14:33
• Action taken between 21:58 and 22:14: enabled VirtualMachinePlatform + HypervisorPlatform + Microsoft-Windows-Subsystem-Linux Windows features + reboot + installed WSL2 from Microsoft Store
• Recovery log signature: [info] [startVM] VM already connected

Implication

The 17,135-line ENOENT retry loop should ideally:

1. Stop retrying after N failed attempts and surface a clear CoworkVMService not runningerror to the UI with specific Windows feature dependency hints, rather than spinning silently
2. Or proactively check Windows feature prerequisites at app startup and prompt the user before letting the VM service silently fail to launch

Happy to share the full log if it helps — %APPDATA%\Claude\logs\cowork_vm_node.log (~2.2 MB). Or specific timestamps if maintainers want narrower windows.

Additional data point — Windows on ARM64 (Snapdragon X), same OS build, two distinct failure modes

Same Windows build as OP (26200 / 25H2, WSL 2.7.3.0, kernel 6.6.114.1-1) but on ARM64. All three features this issue names — Virtual Machine Platform, Windows Hypervisor Platform, WSL — are enabled, vmcompute is running, and CoworkVMService reaches RUNNING, yet Cowork still fails.

Environment

Device   : ASUS Vivobook S 15 (S5507QA)
CPU      : Snapdragon X Plus X1P42100 (Qualcomm Oryon, 8C/8T), ARM64
RAM      : 15.6 GB
OS       : Windows 11 Pro 25H2, Build 26200.8524
WSL      : 2.7.3.0 / kernel 6.6.114.1-1
Claude   : v1.11187.1.0 (arm64 MSIX)

I hit two separate failures:

1. "VM service not running. The service failed to start." — On my machine this was not missing features. It was a deferred MSIX registration: the app auto-updated (1.10628 → 1.11187) while the previous version was still running (a hung workspace VM kept processes alive), so Microsoft-Windows-AppXDeploymentServer/Operational logged:

Event 658: Marking package {Claude_1.11187…} for deferred registration because {Claude_1.10628…} is still running.

The packaged service CoworkVMService (WIN32_PACKAGED_PROCESS, LocalSystem) then couldn't be activated — no SCM 700x events, and Get-AppxPackage still reported Status: Ok (misleading). Fix that worked, no reinstall needed:

# fully quit Claude first (incl. any orphaned vmmem/vmwp), then:
Get-AppxPackage *Claude* | % { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml" }

→ CoworkVMService goes to RUNNING. Suggest the installer/first-run force-finalize a deferred registration (or refuse to swap versions while a VM is live).

2. Underlying "VM connection timeout after 60 seconds." With the service running, the VM boots fully but the guest agent never connects host↔guest. Began ~June 3, coincident with the 26200.8524 update. Survives reboot, fresh rootfs.vhdx re-download, fresh smol-bin.vhdx, and clean service re-registration. Since the VM platform features are all enabled here, this looks like a guest↔host transport (Hyper‑V socket/vsock) regression on 25H2 build 26200.8524, distinct from the missing-feature cause above. Full trace:

[VM:steps] create_network completed (2ms)
[VM:steps] create_vm_config completed (135ms)
[VM:steps] vm_boot completed (150ms)
[VM:steps] add_plan9_shares completed (4ms)
[VM:start] Still waiting for guest connection... 10177ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20339ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30450ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 40671ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 50903ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

cowork_vm_node.log

Echoing same-OS-build data point.

Running Windows 11 Pro 25H2, Build 26200.8524, WSL 2.7.3.0, kernel 6.6.114.1-1 — same OS build as @vsaintloup, different CPU arch (x86_64 here vs. ARM64 there).

Have not personally hit the VM connection timeout failure mode yet, but flagging the build-26200.8524 transport-regression hypothesis for any Anthropic investigation — this build appears across both arch families now.

Original CoworkVMService start-failure repro from the OP (this thread) still stands on my side; @vsaintloup's deferred-MSIX-registration data point is a useful additional cause for "service not running" that I had not seen.

<html>
<body>
<!--StartFragment--><html><head></head><body>
<p><strong>Follow-up: uninstalling KB5092427 does <em>not</em> fix it — ruling out the Windows update</strong></p>
<p>Following my earlier ARM64 report, I tested the Windows-update hypothesis directly. <strong>Removing the suspected update does not help:</strong></p>
<ul>
<li>Uninstalled <strong>KB5092427</strong>, rebooted → confirmed gone (<code>Get-HotFix -Id KB5092427</code> returns nothing).</li>
<li>Notably, the OS build/UBR <strong>did not even change</strong> — still <code>26200.8524 (25H2)</code> after removal — so KB5092427 wasn't what set this build in the first place.</li>
<li>The very next VM start (fresh boot, <code>CoworkVMService</code> Running, ~3 GB free) <strong>fails identically</strong>:</li>
</ul>
<pre><code>[VM:start] Beginning startup
[VM:steps] add_plan9_shares completed
Still waiting for guest connection... 10195ms / 21 polls
Still waiting for guest connection... 20236ms / 40 polls
Still waiting for guest connection... 30486ms / 60 polls
Still waiting for guest connection... 40666ms / 80 polls
Still waiting for guest connection... 50791ms / 100 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds
</code></pre>
<p>The failure is <strong>fully deterministic</strong> — every attempt stalls at the same step (<code>add_plan9_shares</code>), polls ~100 times, and times out at exactly 60 s. That consistency argues against a resource/timing race and points to the guest never being able to open the host↔guest channel at all.</p>
<p><strong>What I've now ruled out on this machine</strong> (ASUS Vivobook S15, Snapdragon X Plus X1P42100, Win 11 ARM64 25H2 build 26200.8524, Claude 1.11187.4.0):</p>

Ruled out | Result
-- | --
Full reboot | no change
Fresh rootfs.vhdx / smol-bin.vhdx re-download | no change
CoworkVMService re-registration (now Running) | fixed the service error, timeout remains
VM Platform / Hypervisor Platform / WSL features | all enabled; vmcompute running
Uninstalling KB5092427 | no change

<p>So on ARM64 this is <strong>not</strong> the missing-feature cause from the top of this thread, and <strong>not</strong> a Windows-update regression that users can roll back. It looks like a guest↔host transport (Hyper-V socket / vsock) failure specific to the Cowork micro-VM on Windows-on-ARM 25H2.</p>
</body></html><!--EndFragment-->
</body>
</html>

Conclusive root-cause evidence — ARM64 / Snapdragon X: guest OS never boots

Follow-up to my earlier ARM64 reports, now with admin-level HCS diagnostics. This lines up
exactly with the two other open Snapdragon reports (#39161, #39636).

Machine: ASUS Vivobook S15 (S5507QA), Snapdragon X Plus X1P42100 (Qualcomm Oryon, ARM64),
Win 11 Pro 25H2 build 26200.8524, Claude 1.11187.4.0 (arm64 MSIX), WSL 2.7.3.0 / kernel 6.6.114.1-1.

1. Host VM lifecycle is perfect — failure is 100% guest-side.
Polling hcsdiag list (admin) during a workspace start shows the compute system at
state Running continuously for the full ~60 s window:

12:18:20 VM, Running, 438F3AE5-054D-5FBF-8BB1-EF6E9BB15822, cowork-vm-746e2ee5
... (Running every poll for ~67s) ...
12:19:27 VM, Running, 438F3AE5-054D-5FBF-8BB1-EF6E9BB15822, cowork-vm-746e2ee5

App side, same window:

[VM:start] Still waiting for guest connection... 50xxxms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

2. The partition runs, but there is no attachable guest.
While hcsdiag list continuously reports that ID as Running, hcsdiag exec against the
same ID fails instantly on every attempt:

hcsdiag exec 438F3AE5-... /bin/sh -c "uname -a"
-> A virtual machine or container with the specified identifier does not exist.

i.e. the hypervisor partition is executing, but HCS can attach no process — no live guest
compute service. The guest OS never initializes, so nothing ever opens the vsock back.
(Consistent with #39636's "guest daemon log completely empty".)

3. Host transport stack confirmed fully healthy — rules out the OP's missing-feature cause.
HvHost, vmcompute, hns, vmsmp, hvservice, vfpext all Running;
GuestCommunicationServices registry has the standard VM Session Service GUIDs; bundle
(vmlinuz 57 MB, initrd, rootfs.vhdx, smol-bin.vhdx) intact and freshly unpacked;
CoworkVMService Running, named pipe present.

Same failure as #39161 and #39636 (both Snapdragon X); same signature as #44007 / #42784.

Conclusion / hypothesis: the bundled ARM64 Cowork guest kernel (vmlinuz) doesn't boot
on Snapdragon X (Qualcomm Oryon) — likely missing CONFIG_HYPERV / hv_sock or required
Oryon support. WSL2's aarch64 kernel boots fine on this exact device, and Cowork ships its
own kernel (not WSL's), so this is isolated to the Cowork guest image — not the host, not Windows.

Asks for maintainers:

1. Is the ARM64 Cowork vmlinuz built with Hyper-V guest transport (hv_vmbus/hv_sock)

and validated on Snapdragon X?

1. Please surface the guest serial/console log on timeout so this is diagnosable without hcsdiag.

@vsaintloup — thank you for the rigorous follow-up. The three data points strengthen the cluster materially:

1. Snapdragon X / ARM64 same OS build (Windows 11 26200 / 25H2) — confirms the symptom is not x86_64-specific.
2. Uninstalling KB5092427 does not fix it — rules out the suspected Windows update as the regression trigger.
3. Admin-level HCS evidence: guest OS never boots — moves the failure mode from "transient runtime stall" to "provisioning-time failure", which is a much sharper diagnostic anchor for the Cowork VM service path.

Combined with the earlier x86_64 reports and the WSL2 Linux side-band in the #54847 lineage, this looks platform-independent (host-side) and architecture-independent (x86_64 + ARM64) — the common factor is the Cowork VM service initialization path on Windows 11. Hopefully this consolidates enough signal for a triage pass once the team gets to it.

Will leave the thread to accumulate any further data points; not piling on additional reports from my side.

Confirming this from a different configuration — Windows 11 Home, Claude Desktop 1.11847.5, i7-1065G7:

• Symptom identical: "VM service not running," restart/reboot/workspace-reinstall all ineffective
• Root cause on my system: HypervisorPlatform alone was Disabled (VirtualMachinePlatform already Enabled, VT-x on). Enabling just HypervisorPlatform + reboot fully resolved it — CoworkVMService now Running, workspace functional
• Cowork had previously worked on this machine with no changes by me, suggesting a Windows update disabled the feature or a Desktop update changed backend requirements (similar to the regression in #27384)
• Notably, #64258 shows a HYPERVISOR_VIRT_DISABLED detection path exists — but it never fired on my config; I only got the generic service error. The detection appears inconsistent across configurations.

Log signature: repeated "[vm-client] Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service" in cowork_vm_node.log. Full diagnostics in #67140 (closing as duplicate of this).

+1 for the preflight check and actionable error message.

Adding a distinct sub-cluster to this thread — same error banner ("VM service not running"), but a different root-cause layer that the manual Windows-feature workaround does not fix.

Key difference from the OP: In my case the VM boots successfully, but the failure happens after boot, during postConnect SDK initialization, which loops silently and then the frontend crashes. So unlike #64592, enabling Virtual Machine Platform / WSL2 / Hypervisor Platform does not resolve it — those are already enabled on my machine, and the service itself is healthy.

Environment

• OS: Windows 11 25H2, Build 26200.8655, x64
• Claude Desktop: 1.12603.1.0 (MSIX / Microsoft Store install)
• claude-code-vm: 2.1.170 (confirmed in main.log: Wrote SDK version file: 2.1.170 / Initialized with version 2.1.170)
• WSL: 2.7.8.0 / Kernel 6.18.33.1-1 / WSLg 1.0.73.2 / MSRDC 1.2.6676 / Direct3D 1.611.1-81528511
• Windows features: VirtualMachinePlatform / WSL2 / Hypervisor Platform / Hyper-V — all Enabled
• Hardware: brand-new PC, hardware virtualization enabled in BIOS

Symptom

• Chat tab works normally.
• Cowork / Claude Code tab crashes on the FIRST message of every new task.
• The VM boots, then postConnect SDK init loops silently before the frontend crash.

Important: the service itself is healthy

Get-Service CoworkVMService | Select Status returns Running at the moment of the crash. So this is NOT the "service stopped after reboot/sleep" cluster — the service is up, the VM boots, and the failure is strictly in the post-boot postConnect SDK handshake.
(Note: there is no CoworkVMServiceStore service; the only service is CoworkVMService, per the package manifest.)

Already tried (all failed)

1. Restart Claude / reboot PC / "reinstall the workspace"
2. Confirmed all required Windows features enabled (so the #64592 workaround is N/A)
3. Confirmed CoworkVMService = Running at crash time (rules out the service-stopped cluster)
4. Clean delete of vm_bundles / claude-code-vm folders + re-register MSIX package

Why this looks like a claude-code-vm 2.1.170-specific regression

The VM layer itself is healthy (service Running, VM boots); the failure is in the host↔VM SDK handshake after connect. The silent postConnect loop with no surfaced error suggests a bug in the 2.1.170 VM client rather than a Windows virtualization-stack dependency.

Log excerpt (paths sanitized)

From main.log (username replaced with <USER>):

main.log: 2026-06-13 14:00:43 [info] [CCD] Wrote SDK version file: 2.1.170
main.log:   executable: 'C:\Users\<USER>\AppData\Roaming\Claude\claude-code\2.1.170\claude.exe'
main.log: 2026-06-13 14:09:06 [info] [CCD] Initialized with version 2.1.170
main.log: 2026-06-14 07:49:35 [info] [CCD] Initialized with version 2.1.170
main.log: [info] [VM] getVMStorageSubpath: vmStorageDir=C:\Users\<USER>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code-vm

Happy to attach the full cowork_vm_node.log lines from the postConnect-loop window and the relevant Event Viewer entries (Service Control Manager / Hyper-V / HNS). Could a maintainer confirm whether 2.1.170 has a known postConnect init regression, and whether a downgrade / pinned VM version is available as an interim?

Another variant of this cluster — same symptom, but on a machine where the VM features were already enabled and healthy. Root cause here was the packaged service failing to start within the app's timeout, not a missing Windows feature.

Environment

• Windows 11 Pro, Build 26200.8655, x64
• Claude Desktop 1.12603.1.0 (MSIX, Claude_1.12603.1.0_x64__pzs8sxrjxfjjc)
• WSL 2.7.3.0 / Kernel 6.6.114.1-1
• Virtualization stack present and healthy at failure time: HvHost, vmcompute, vmms, WSLService all Running → the "enable VM Platform + WSL2" workaround in this thread did not apply.

What actually failed
CoworkVMService (MSIX packaged service cowork-svc.exe) was simply Stopped, and the pipe \\.\pipe\cowork-vm-service didn't exist. Every startup attempt in %APPDATA%\Claude\logs\cowork_vm_node.log did:

[VM:start] Configuring Windows VM service...
(~5s later)
[VM:start] Startup failed: Error: VM service not running. The service failed to start.
[VM:start] Skipping auto-reinstall (already attempted once)

The "Configuring Windows VM service" step times out after ~5s and then latches Skipping auto-reinstall (already attempted once) for the rest of the session, so it never reconnects even once the service is up.

Workaround (no admin, no feature changes)

Start-Service CoworkVMService

Service goes to Running instantly and creates the pipe; a new Cowork session then connects normally (the packaged service's ACL allowed a non-elevated start). Pre-starting it before opening Cowork avoids the race.

Downstream consequence (ties this to the MSIX-reopen bug #26457)
Leaving CoworkVMService running is itself risky: as an MSIX packaged-process service, a running cowork-svc.exe holds package files. A later app update couldn't replace the locked package, the app stopped launching entirely, and the only recovery was removing the MSIX and reinstalling the Squirrel .exe build — which permanently disables Cowork (verified in logs: [warm] Skipping VM warm download - YukonSilver not supported, app then deletes the VM bundle). So "VM service won't start" and "MSIX reopen/update fails" look like two ends of the same packaged-service lifecycle problem.

Suggestions

1. Raise the "Configuring Windows VM service" timeout and/or poll the pipe after the service reports Running, instead of aborting the session after one attempt.
2. Don't latch Skipping auto-reinstall (already attempted once) for the whole session — re-arm on reopen.
3. Stop a running CoworkVMService during package update to avoid the lock that bricks relaunch.

Happy to provide full logs.

Follow-up to @FuturiaMarketing's workaround — tried it, but my case fails one layer deeper (service is Running, still crashes)

Thanks @FuturiaMarketing — we're on nearly identical hardware (Windows 11 Pro, Build 26200.8655, MSIX Desktop, WSL2, virtualization stack healthy). I tried your Start-Service CoworkVMService workaround, but it does not resolve my case, and the reason is an important distinction between our two reports:

• Your case: CoworkVMService was Stopped and the pipe \\.\pipe\cowork-vm-service didn't exist → starting the service fixes it. (service-won't-start)
• My case: CoworkVMService is already Running before and after the crash, yet Cowork still crashes on the first message of every new task. (service-runs-but-postConnect-fails)

What I did, step by step:

1. Fully quit Claude Desktop (incl. tray).
2. Admin PowerShell: Start-Service CoworkVMService → completed; Get-Service CoworkVMService | Select Status → Running.
3. Launched Claude Desktop with the service confirmed Running, opened Cowork, sent "こんにちは" (hello) → "Claude Code crashed" immediately, same as always.

So pre-starting the service (your race-avoidance trick) doesn't help here — the service is up, the pipe should exist, but the post-connect handshake still fails. This lines up with what I see in the Windows System log: Service Control Manager 7034 "The Claude service terminated unexpectedly" and 7011 (timeout) recurring across multiple days — i.e. the service starts, then dies again, rather than never starting.

Things already ruled out on my machine (all still reproduce):

• Restart Claude / reboot PC / reinstall workspace
• Update 1.12603.1.0 → 1.13576.0 (large version jump, no change)
• Help → Troubleshooting → Clear Cache and Restart
• Pre-starting CoworkVMService (this workaround) — service Running, still crashes

I think your suggestions about the "Configuring Windows VM service" timeout and the latched Skipping auto-reinstall (already attempted once) are spot-on, and my case may be the same lifecycle bug seen from the other side: the service can start, but the app's post-connect init still aborts after one attempt and never recovers within the session.

Could a maintainer treat "service Running but postConnect still fails (7034/7011 recurring)" as a separate failure mode from "service won't start"? Happy to share full cowork_vm_node.log and the raw 7034/7011 events (paths sanitized).

Adding a full data point to this cluster, since the "enable virtualization features" workaround didn't resolve it for me — happy to share the full diagnostic bundle if useful.
Setup: Windows 10 (10.0.19045), Claude desktop 1.20186.1 (MSIX/Windows Store install), Intel i7-2600, 8GB RAM. Device id desktop-t7ahhqq.
Timeline: Bridge (Cowork device/file/computer-use tools) has failed to connect for 48+ hours across many attempts, including a full appdata clear and reinstall.
Diagnostic bundle (captured 2026-07-13, shortly after the appdata clear): shows the local Cowork VM repeatedly failing to start:
[VM:start] Startup failed: Error: VM service not running. The service failed to start.
[vm-client] Event resubscribe failed: Error: connect ENOENT <unc>\cowork-vm-service
with a later attempt instead failing as request timed out after 30s. Separately, the lighter remote-tools-device websocket component (which carries the file/computer bridge tools, distinct from the full VM sandbox) logged a successful reconnect and authenticated event against wss://bridge.claudeusercontent.com/devices/.../desktop-t7ahhqq/bridge — but a live session targeting this device showed zero bridge tools available both immediately afterward and on every recheck since. So this isn't simply "won't connect" — the app-side auth can succeed while a session never actually gets wired to use it.
Tried the fix from this thread: Virtual Machine Platform and WSL2 were already enabled; added Windows Hypervisor Platform, installed WSL2 from the Microsoft Store, did a full restart (not just relaunching the app). Bridge still fails exactly as before — no change. So whatever's happening here looks like a different failure mode than the "virtualization features were off" cause that fixed things elsewhere in this cluster.
Also flagging: the in-app Fin support widget for this account has been stuck on an unanswered thread (5–6 messages, no reply) for several days, with no way to open a new one — so this GitHub thread has been the only avenue available to report this.
Glad to provide the full diagnostic export, exact log timestamps, or anything else that would help triage.

Update on my earlier comment: alongside the technical bug above, I want to flag how badly the Anthropic support side has failed here too, since it's relevant context for anyone else stuck in this cluster.
Days before my comment above, I'd been told via the in-app support widget: "We're transitioning your question to one of our human support agents for further assistance. You don't need to keep this window open - we'll email you when an agent has responded." Conversation ID: 215475061682604. Since then: no email, no follow-up, and the thread itself became permanently stuck with no way to reopen it — which is what forced me onto GitHub as the only remaining avenue, and eventually a second account just to get a working support chat at all.
Obviously this repo isn't the official support channel, but given that the official channel demonstrably failed on a specific, timestamped promise, I think it's fair to note here for visibility. If anyone from Anthropic is reading this thread for the underlying VM bug, I'd be grateful if the support failure could also get a look.