[BUG] CoworkVMService never completes VM creation — stuck in silent connect/disconnect loop (device_bash / Workspace unavailable)

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?

Summary

On Windows, the Cowork desktop app's isolated Linux workspace (used by device_bash and related remote-devices tools) fails to start. Every attempt returns:

"Workspace unavailable. The isolated Linux environment on this device failed to start."

The CoworkVMService Windows service starts correctly, initializes HCS/HCN, and opens its named pipe server — but the log shows it never progresses past accepting client connections. It never logs a configure call being received, never logs a VM being created, and never logs an error. The service log fills indefinitely with [Server] Client connected lines (one attached, ~2,700 lines from a single ~19-hour period) with no other content after the startup block.

This looks like a silent failure in the handshake between the desktop app and CoworkVMService — most likely at the signature-verification step logged right before the pipe server starts (Enforce: true), since the service accepts the pipe connection but the app never reaches the point of sending configure, and nothing is logged explaining why.

Note: this may be related to previously closed GitHub issues #55649, #56145, and #57968 (closed as "not planned"), but this report includes a fuller log capture showing the exact point where the process gets stuck, which those issues did not have.

Environment

• OS: Windows 11 (device name: AcerNitro / Acer_Nitro)
• Hardware: Acer Nitro laptop, dual GPU (AMD Radeon integrated + NVIDIA GeForce RTX 3050 Laptop GPU)
• Claude package: Claude_1.34493.1.0_x64__pzs8sxrjxfjjc (MSIX / WindowsApps install)
• Virtualization stack present on this machine:
• Hyper-V: enabled (Microsoft-Hyper-V-All)
• Windows Hypervisor Platform: enabled
• VMware Workstation Pro: installed, with background services running (VMware Authorization Service, VMware NAT Service, VMware USB Arbitration Service, VMware VMnet DHCP service) and virtual adapters VMnet1/VMnet8
• WSL2: installed, not running at time of testing (wsl --list --running → no distros running)
• Smart App Control: disabled (VerifiedAndReputablePolicyState = 0)
• No relevant Code Integrity denials in Microsoft-Windows-CodeIntegrity/Operational tied to any Claude/Cowork process (the only CI errors present are unrelated, from Office's aimgr.exe trying to load an NVIDIA capture DLL)
• Get-VM returns empty (no classic Hyper-V VMs registered)
• hcsdiag list returns empty
• No persistent vmwp.exe process found via Get-Process at time of testing (it may appear only transiently — was seen once in Task Manager as "Proceso de trabajo de máquina virtual" but could not be caught with Get-Process -Name vmwp moments later)

Steps already taken (did not resolve the issue)

1. Confirmed Microsoft-Hyper-V-All was disabled, enabled it, rebooted.
2. Confirmed HypervisorPlatform was already enabled.
3. Checked Windows Event Viewer and C:\ProgramData\Claude\Logs\cowork-service.log:

• CoworkVMService starts, loads HCS/HCN DLLs without error, opens named pipe.
• Minor unrelated warning: failed to configure recovery actions ... Access is denied (does not appear to be the root cause — only affects automatic restart-on-crash).
• Real symptom: log fills with [Server] Client connected once per second (or in bursts), indefinitely, with no VM-creation log line ever appearing.

1. Ruled out duplicate Claude packages (Get-AppxPackage *Claude* shows a single install, Status: Ok).
2. Ruled out Windows Defender blocking (Protection History showed nothing related).
3. Performed a full clean reinstall: uninstalled Claude, ran sc.exe delete CoworkVMService to clear a service registration with broken permissions, deleted C:\ProgramData\Claude, reinstalled from scratch, rebooted. Symptom persisted identically after reinstall.
4. Ruled out Smart App Control (confirmed disabled via registry).
5. Ruled out Code Integrity/WDAC blocking a Claude-signed binary (no relevant events in the CodeIntegrity operational log).
6. Ruled out a currently-active hypervisor conflict with VMware Workstation or WSL2 (Get-VM, hcsdiag list, and wsl --list --running all show nothing running at the time of testing).
7. Set up a scheduled task to periodically truncate cowork-service.log (Clear-Content every hour) as a stopgap so the log doesn't grow unbounded while this is unresolved — this is a workaround, not a fix.

Log evidence

Every line in the attached log after the startup block is [Server] Client connected, repeating for ~2,700 lines over ~19 hours, with zero other log lines (no errors, no configure received, no VM creation attempt, no timeout messages). Startup block for reference:

2026/08/22 19:04:36.644759 Starting CoworkVMService as Windows service
2026/08/22 19:04:36.688199 Claude VM Service starting...
2026/08/22 19:04:36.688199 Waiting for configuration from app via 'configure' method...
2026/08/22 19:04:36.688199 [HCS] Initializing HCS DLLs...
2026/08/22 19:04:36.693982 [HCS] vmcompute.dll loaded successfully
2026/08/22 19:04:36.694506 [HCS] computecore.dll loaded successfully
2026/08/22 19:04:36.694506 [HCS] Procs initialized, HCS ready
2026/08/22 19:04:36.694506 [HCN] Initialized HCN API from computenetwork.dll
2026/08/22 19:04:36.698223 [HCN] EnumerateNetworks result: ["c08cb7b8-9b3c-408e-8e30-5e16a3aeb444"]
2026/08/22 19:04:36.981555 [Server] Signature verification initialized
2026/08/22 19:04:36.981555 [Server]   Service: C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe
2026/08/22 19:04:36.981555 [Server]   Subject: Anthropic, PBC
2026/08/22 19:04:36.981555 [Server]   Thumbprint: dbde5d16768ed0c1...
2026/08/22 19:04:36.981555 [Server]   Package: Claude_pzs8sxrjxfjjc (C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc)
2026/08/22 19:04:36.981555 [Server]   Enforce: true
2026/08/22 19:04:36.981555 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/08/22 19:04:36.982084 [Server] Named pipe server listening
2026/08/22 19:04:36.982084 Service ready. Listening on \\.\pipe\cowork-vm-service
2026/08/22 19:04:36.982606 Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
2026/08/22 19:04:39.769315 [Server] Client connected
2026/08/22 19:04:39.786686 [Server] Client connected
... (repeats ~2,690 more times, no other content) ...

Full log attached separately (cowork-service.log).

What would help

• Confirmation of what happens between "Client connected" and "configure received" in cowork-svc.exe — specifically whether the signature check on the connecting client process can fail silently without logging.
• Any additional debug/verbose logging flag that could be enabled to capture more detail at that handshake step.
• Whether this is a known interaction with WindowsApps/MSIX sandboxing (AppContainer) permissions on named pipes on some Windows configurations.

Impact

device_bash and any workflow requiring the isolated Linux workspace on this device are completely unusable. The file-based bridge tools (device_stage_files, device_commit_files, device_list_dir) work fine and are unaffected — only the shell/VM path is broken.

cowork-service.log

What Should Happen?

CoworkVMService should complete the handshake with the desktop app, receive the configure call, and successfully create the isolated Linux VM so that device_bash and related remote-devices tools work — instead of looping indefinitely on [Server] Client connected with no error and no progress toward VM creation.

Error Messages/Logs

Steps to Reproduce

1. On Windows, with Cowork desktop app installed and a folder connected, start a Claude Code / Cowork session.

From the session, call any tool that requires the local device shell (e.g. device_bash with a simple command like echo ok).

1. Observe the error: "Workspace unavailable. The isolated Linux environment on this device failed to start."
2. Check C:\ProgramData\Claude\Logs\cowork-service.log — the service starts, initializes HCS/HCN, opens its named pipe, and logs [Server] Client connected repeatedly (once per second or in bursts) but never logs a configure call being received, a VM being created, or any error.
3. Confirmed this persists after: enabling Hyper-V, confirming Windows Hypervisor Platform is enabled, and a full clean reinstall of Claude (uninstall, sc.exe delete CoworkVMService, delete C:\ProgramData\Claude, reinstall, reboot).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Versión 1.34493.1 (255293)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

_No response_