[BUG] Cowork / Claude Desktop (Windows MSIX): VM service fails to start ~48 hours after MSIX re-registration; named pipe never created

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?

Opening a Cowork workspace in Claude Desktop (Windows MSIX, v1.7196.0.0) fails with:

"Failed to start Claude's workspace. VM service not running. The service failed to start."

In %APPDATA%\Claude\logs\cowork_vm_node.log, the app reaches [VM:start] Configuring Windows VM service... then throws Error: VM service not running. The service failed to start.

This is followed by indefinite once-per-second warnings: connect ENOENT \\.\pipe\cowork-vm-service. The named pipe \\.\pipe\cowork-vm-service is never created, meaning the per-app VM host process spawned by Claude Desktop never starts.

The failure recurs on a roughly 48-hour cycle. The only workaround is a manual MSIX re-registration (Add-AppxPackage -DisableDevelopmentMode -Register), which restores functionality for ~48 hours before failing again.

A correlation exists with auto_reinstall_attempted marker file being dropped in vm_bundles\claudevm.bundle\ approximately 11 minutes before failures resume, suggesting Cowork's own auto-reinstall flow corrupts the packaged host process activation state.

What Should Happen?

Opening a Cowork workspace should start the VM host service reliably, publish the named pipe \\.\pipe\cowork-vm-service, and remain stable without requiring periodic MSIX re-registration. The Cowork auto-reinstall flow should not corrupt the packaged host process activation state.

Error Messages/Logs

[VM:start] Configuring Windows VM service...
Error: VM service not running. The service failed to start.

Then repeating (once per second):
connect ENOENT \\.\pipe\cowork-vm-service
connect ENOENT \\.\pipe\cowork-vm-service
...

The named pipe \\.\ pipe\cowork-vm-service is never created.

Full logs available on request:
- %APPDATA%\Claude\logs\cowork_vm_node.log (contains the failing stack trace)
- %APPDATA%\Claude\logs\main.log
- Windows Event Viewer: Microsoft-Windows-Hyper-V-Compute-Admin and Microsoft-Windows-AppXDeployment/Operational

Steps to Reproduce

1. Install Claude Desktop via MSIX (package Claude_1.7196.0.0_x64__pzs8sxrjxfjjc) on Windows with Hyper-V enabled (vmcompute and HvHost services running), WSL not installed.
2. Perform initial MSIX re-registration via Add-AppxPackage -DisableDevelopmentMode -Register "<install>\AppxManifest.xml" (or Settings → Apps → Repair).
3. Open a Cowork workspace — it starts successfully.
4. Wait approximately 48 hours. (Cowork's auto-reinstall flow will drop an auto_reinstall_attempted marker in vm_bundles\claudevm.bundle\ roughly 11 minutes before failure.)
5. Attempt to open a Cowork workspace again.
6. Observe the error: "Failed to start Claude's workspace. VM service not running. The service failed to start."
7. Check %APPDATA%\Claude\logs\cowork_vm_node.log — see [VM:start] Configuring Windows VM service... followed by the error and repeated connect ENOENT \\.\pipe\cowork-vm-service messages.

Reproducible on demand: wait 48 hours after any successful MSIX re-registration.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown (version prior to 1.6608.2.0)

Claude Code Version

Claude Desktop 1.7196.0.0 (MSIX: Claude_1.7196.0.0_x64__pzs8sxrjxfjjc); also reproduced on 1.6608.2.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment

• Windows, Claude Desktop MSIX install, package Claude_1.7196.0.0_x64__pzs8sxrjxfjjc
• - Hyper-V virtualisation enabled; vmcompute and HvHost services running
• - - WSL not installed (Cowork ships its own VM bundle)
• - - - C: drive 217.8 GB total, 34.8 GB free (16%)
• - - - - App version stable at 1.7196.0.0 throughout the failure period — not an update regression

Timeline

• 12 May 2026 — first failure, immediately after auto-update to v1.6608.2.0
• - 15 May 2026 — re-registered the MSIX package via Add-AppxPackage -DisableDevelopmentMode -Register "<install>\AppxManifest.xml" (equivalent to Settings → Apps → Repair). Workspace started normally.
• - - 15–17 May — worked fine.
• - - - 17 May 11:16 — Claude Desktop's own auto_reinstall_attempted marker file dropped in vm_bundles\claudevm.bundle\. Failures resumed at 11:27.
• - - - - 17 May 13:06 — re-ran the same MSIX re-register; workspace started again.

What's Been Ruled Out

• WSL — not used by Cowork
• - Hyper-V services — running
• - - Hardware virtualisation — present
• - - - Bundle file corruption — files re-download cleanly; same failure with fresh bundle
• - - - - Single bad app version — failure has occurred on both 1.6608.2.0 and 1.7196.0.0
• - - - - - App's own in-built "reinstall workspace" — wipes rootfs.vhdx / vmlinuz / initrd but does not fix the host-service registration

What Works (Temporarily)

Re-registering the MSIX package via Add-AppxPackage -Register fixes it for about 2 days, then the same failure recurs. The correlation with the auto_reinstall_attempted marker file suggests Cowork's own auto-reinstall flow is corrupting the packaged host process activation state.

Question for Engineers

What component of the Claude Desktop install state degrades within 48 hours of a successful MSIX re-registration, causing the per-app cowork-vm-service host process to fail to start (and never publish its named pipe)? Is this a known issue with the packaged background task / COM server registration in the current Cowork build?

Logs Available on Request

• %APPDATA%\Claude\logs\cowork_vm_node.log (contains the failing stack trace)
• - %APPDATA%\Claude\logs\main.log
• - - Windows Event Viewer: Microsoft-Windows-Hyper-V-Compute-Admin and Microsoft-Windows-AppXDeployment/Operational

Happy to send the logs or jump on a call. Reproducible on demand — just wait 48 hours after last re-register.