[BUG] Cowork: CoworkVMService runs but never creates \\.\pipe\cowork-vm-service on Windows 11 ARM64 (Snapdragon X) — WIN32_PACKAGED_PROCESS sandbox blocks pipe creation

Open 💬 1 comment Opened Jun 24, 2026 by somiljohari

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 the Cowork tab fails with "Failed to start Claude's workspace — VM service not running. The service failed to start." CoworkVMService starts and stays Running, but it never creates its control named pipe \\.\pipe\cowork-vm-service, so the app retries the pipe connection once per second indefinitely (connect ENOENT \\.\pipe\cowork-vm-service). No Hyper-V VM is ever created.

The service is registered as TYPE: 210 WIN32_PACKAGED_PROCESS, which inherits MSIX AppContainer sandbox restrictions and prevents named-pipe creation even though the service runs as LocalSystem. This is the same root cause documented in #48468 and #56195, but those reports are all on x64. This report confirms the bug reproduces identically on ARM64 / Snapdragon X, so it is not architecture-specific.

Environment

Device: Snapdragon X1 (Windows on ARM)
OS: Windows 11 Pro, ARM64
Claude Desktop: 1.15200.0.0 (MSIX)
Package: Claude_1.15200.0.0_arm64__pzs8sxrjxfjjc
Install location: C:\Program Files\WindowsApps\Claude_1.15200.0.0_arm64__pzs8sxrjxfjjc
Virtualization stack: vmcompute Running, vmms Running, WSL2 + Ubuntu present and healthy (wsl -l -v shows Ubuntu v2)

Service configuration (sc.exe qc CoworkVMService)

SERVICE_NAME: CoworkVMService
TYPE : 210 WIN32_PACKAGED_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 0 IGNORE
BINARY_PATH_NAME : "C:\Program Files\WindowsApps\Claude_1.15200.0.0_arm64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
DISPLAY_NAME : Claude
DEPENDENCIES : staterepository
SERVICE_START_NAME : LocalSystem

Diagnostic evidence

Service runs but pipe is never created:

PS> Start-Service CoworkVMService
PS> Get-Service CoworkVMService # -> Running
PS> Test-Path \\.\pipe\cowork-vm-service # -> False
PS> Get-VM # -> (no VMs; no cowork VM ever registered)

cowork-service.log — service initializes then goes silent (never logs pipe creation):

Starting CoworkVMService as Windows service
Claude VM Service starting...
Waiting for configuration from app via 'configure' method...
[HCS] Initializing HCS DLLs...
Warning: failed to open service for recovery config: Access is denied.
[HCS] vmcompute.dll loaded successfully
[HCS] computecore.dll loaded successfully
[HCS] Procs initialized, HCS ready
[HCN] Initialized HCN API from computenetwork.dll
[HCN] EnumerateNetworks result: ["c08cb7b8-9b3c-408e-8e30-5e16a3aeb444"]
<-- no further output; pipe is never created, no VM configured -->

cowork_vm_node.log — app side loops forever waiting for the pipe:

[VM:start] Skipping auto-reinstall (already attempted once)
[warn] [vm-client] Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service
[warn] [vm-client] Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service
(repeats every ~1 second indefinitely)

Recurring 30-second stop-timeout on every service cycle (resources not released cleanly between sessions):

Service stop requested
Timeout waiting for service to stop
Starting CoworkVMService as Windows service

Steps to Reproduce

Install Claude Desktop ARM64 (MSIX) on a Snapdragon X / Windows 11 Pro ARM64 machine.
Confirm WSL2 + Ubuntu installed and virtualization features enabled (Virtual Machine Platform, Hypervisor Platform).
Open Claude Desktop → Cowork.
Observe "VM service not running" error; cowork_vm_node.log shows endless ENOENT \\.\pipe\cowork-vm-service.

What I tried (none resolved it)

wsl --shutdown (hung — stuck VM resources from prior session)
Fully quit Claude, killed all claude / vmwp / vmmem / vmcompute processes
Start-Service CoworkVMService from elevated PowerShell — service goes Running, pipe still absent
Restart-Service vmcompute -Force
Launching Claude Desktop as Administrator
App's built-in "reinstall workspace" — reaches Skipping auto-reinstall (already attempted once)
MSIX re-registration: Add-AppxPackage -DisableDevelopmentMode -Register "<install>\AppxManifest.xml" — Test-Path on pipe still False

What Should Happen?

CoworkVMService should create \\.\pipe\cowork-vm-service, the app's configure() step should connect, and the Cowork VM should be created and boot.

Error Messages/Logs

Steps to Reproduce

Install Claude Desktop ARM64 (MSIX) on a Snapdragon X / Windows 11 Pro ARM64 machine.
Confirm WSL2 + Ubuntu installed and virtualization features enabled (Virtual Machine Platform, Hypervisor Platform).
Open Claude Desktop → Cowork.
Observe "VM service not running" error; cowork_vm_node.log shows endless ENOENT \\.\pipe\cowork-vm-service.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop: 1.15200.0.0 (MSIX)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗