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

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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.
4. Ruled out duplicate Claude packages (`Get-AppxPackage *Claude*` shows a single install, `Status: Ok`).
5. Ruled out Windows Defender blocking (Protection History showed nothing related).
6. 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.**
7. Ruled out Smart App Control (confirmed disabled via registry).
8. Ruled out Code Integrity/WDAC blocking a Claude-signed binary (no relevant events in the CodeIntegrity operational log).
9. 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).
10. 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](https://github.com/user-attachments/files/31342176/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

```shell

```

### 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).
2. Observe the error: "Workspace unavailable. The isolated Linux environment on this device failed to start."
3. 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.
4. 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_

Start with the attached C:\ProgramData\Claude\Logs\cowork-service.log and the cowork-svc.exe named-pipe handshake around repeated "Client connected" entries. Trace whether the desktop app reaches the `configure` call after connection and whether signature verification reports failures. Done means the handshake produces an actionable result and CoworkVMService creates the isolated Linux VM instead of looping silently.

Written by the indexing model from the issue text.