[BUG] Cowork: workspace VM never starts — service waits for `configure` forever while client reconnects once per second

Reproducing the same issue on Claude Desktop 1.52386.6.0 on Windows.

Confirmed:

VirtualMachinePlatform enabled
hns, vmcompute, and CoworkVMService running
hypervisorlaunchtype = Auto
Claude installed on C:
claude.exe Authenticode signature = Valid
CoworkVMService is from the same 1.52386.6.0 package

C:\ProgramData\Claude\Logs\cowork-service.log shows [Server] Client connected approximately once per second indefinitely, with no workspace VM startup.

Claude UI reports: “Failed to start Claude’s workspace — RPC pipe closed.”

This appears to confirm that the issue still persists on Desktop 1.52386.6.0.

I am on Claude Desktop 1.52386.6.0 on Windows and the issue persists after the September 14 Microsoft security update.

Additional data point, with a clean post-reboot trace isolating the failure to the app side.

Environment

• Windows 11 25H2, build 26200.9457 (i.e. after the September cumulative + the later fix KB)
• Claude desktop 2.2553.1 (MSIX, x64), service binary app\resources\cowork-svc.exe
• Symptom: every device_bash call returns Workspace unavailable. The isolated Linux environment on this device failed to start.

The rest of the device bridge (device_list_dir / device_stage_files / device_commit_files) works normally.

Service log after a clean reboot (C:\ProgramData\Claude\Logs\cowork-service.log)

13:34:17 Waiting for configuration from app via 'configure' method...
13:34:17 [HCS] Initializing HCS DLLs...
13:34:17 [HCS] vmcompute.dll loaded successfully
13:34:17 [HCS] computecore.dll loaded successfully
13:34:17 [HCS] Procs initialized, HCS ready
13:34:20 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
13:34:20 [Server] Named pipe server listening
13:34:20 Service ready. Listening on \\.\pipe\cowork-vm-service
13:51:14 [Server] Client connected
13:51:15 [Server] Client connected
... (once per second, continuously, for the rest of the session)

HCS initializes cleanly, the pipe listens, the app connects once per second — and configure is never sent. No VM creation is attempted. This matches the original report exactly; unlike some reports here, HCS initialization itself succeeds, so the handshake is the only failing step.

Host prerequisites verified healthy (so these can be ruled out)

• VirtualMachinePlatform, HypervisorPlatform, Microsoft-Windows-Subsystem-Linux: all Enabled
• bcdedit hypervisorlaunchtype Auto; HypervisorPresent True
• Services running: CoworkVMService (LocalSystem), vmcompute, hns, WSLService
• hcsdiag list: only the WSL utility VM — no Claude VM ever created
• \\.\pipe\cowork-vm-service present
• Bundle intact: claudevm.bundle\rootfs.vhdx ~7.6 GB, smol-bin.vhdx mtime updates after each failed attempt, so the app reaches the bundle stage before giving up. No .auto_reinstall_attempted marker present.
• WSL 2.7.14.0, kernel 6.18.33.2-2, default distro running — WSL itself is entirely healthy

Tried, no effect: app reinstall; reboot; installing the later cumulative; enabling HypervisorPlatform and the WSL optional component (both were Disabled — enabling them changed nothing, which rules out the prerequisite-features workaround from the related issue).

Possibly distinguishing detail: on this machine %APPDATA% is redirected to a secondary drive via known-folder redirection, so ...\Claude\vm_bundles\ is not on C:. I have not seen that mentioned in the other reports. If the app resolves the bundle or a socket/state path assuming C:, or assuming a non-redirected %APPDATA%, that would fail silently exactly where this does — before configure. Worth checking whether other affected users also have a redirected %APPDATA%.

Benign noise seen every start, probably unrelated but noting it:

• Warning: failed to configure recovery actions ... open service: Access is denied.
• One week-old [Cleanup] Warning: failed to enumerate HCN networks: HcnEnumerateNetworks failed with HRESULT 0x800706d9, from a start where vmcompute.dll had failed to load; absent from healthy starts.

Request: the service already logs that it is waiting for configure. The app side logs nothing about why it never sends it — a client-side log line at that step (or an error surfaced in the UI instead of the generic "failed to start") would make this diagnosable without log archaeology.

Follow-up to my trace above: I found the cause on this machine, and it is not the VM, the virtualization features or the service. It is the client authentication check, and it fails for anyone whose MSIX apps are installed on a secondary drive.

The line that says it, in the client-side log at %LOCALAPPDATA%\Claude\logs\cowork_vm_node.log, repeating once a second:

[vm-client] Event resubscribe failed: Error: signature verification failed:
client D:\WindowsApps\Claude_2.2553.1.0_x64__pzs8sxrjxfjjc\app\claude.exe
was not started from the package directory
C:\Program Files\WindowsApps\Claude_2.2553.1.0_x64__pzs8sxrjxfjjc

CoworkVMService verifies that the connecting client executable lives inside the registered package directory. On this machine the two sides disagree about where that is:

• Get-AppxPackage reports InstallLocation = C:\Program Files\WindowsApps\Claude_<version>_x64__<pubid>, and Get-Process claude | Select Path agrees.
• The verification code resolves the same running process to D:\WindowsApps\Claude_<version>_x64__<pubid>.

Windows is configured to install new apps to D: ("Storage > Advanced storage settings > Where new content is saved"), so the package's actual files are on D: while the registration path reported by the platform is the C:\Program Files\WindowsApps one. The check appears to compare these as strings, so it rejects a client that is in fact the correct, signed package.

This is exactly what produces the reported symptom. The rejection happens during connection setup, so:

• the service logs only [Server] Client connected once per second, and occasionally Failed to read request: failed to read length: EOF — it never sees a configure, because the client is dropped before sending one;
• the app logs [remote-bash] VM unavailable: RPC pipe closed;
• the user sees Workspace unavailable. The isolated Linux environment on this device failed to start.

Nothing in the service log hints at authentication. The reason exists only in cowork_vm_node.log, which is not the log the error message or the docs point at.

Corroborating detail: the previous version on this machine (1.52386.6.0) ran from D:\WindowsApps on both sides and worked. A reinstall re-registered the package against C:\Program Files\WindowsApps while the files stayed on D:, and Cowork has been dead since that moment. Host prerequisites are all healthy (HCS initializes, vmcompute/hns/WSLService running, bundle intact, WSL fine) — they were never the issue.

Suggested fix: resolve both paths to their final targets before comparing (normalize reparse points, links and the WindowsApps registration path), or authenticate on package identity / signature rather than on a path string. Failing that, at minimum log the rejection service-side and surface "client signature verification failed" in the UI instead of the generic start failure — that alone turns this from a day of log archaeology into a one-line diagnosis.

Workaround for anyone hitting this: if your apps install to a drive other than C:, set the new-app install location back to C: and reinstall the app so the registration and the files agree.

Unrelated observation from the same machine, in case it correlates for others with a non-default setup: copying app\resources\chrome-native-host.exe out of the package fails with "The specified file could not be encrypted" (an EFS error), logged at every start as [Chrome Extension MCP] Failed to copy native host binary. Ordinary writes and copies into the same destination folder succeed, so it is specific to that source file.

Resolved on my machine. Two distinct bugs were stacked, both triggered by a non-default but entirely supported Windows configuration: apps installed to a secondary drive, and %APPDATA% redirected to that drive. Full chain, in case it helps others and the maintainers.

Bug 1 — client signature check fails when the package is on a secondary AppX volume

Reported in my previous comment. CoworkVMService compares the connecting client's executable path against the registered package directory. With apps installed to a second drive, Windows puts the real package under <D>:\WindowsApps\... and exposes it as a junction at C:\Program Files\WindowsApps\.... Get-AppxPackage and Get-Process report the junction path; the check resolves the target. They differ, the client is rejected, configure is never sent, and the service logs only Client connected once per second.

What did not work: Settings > Apps > Advanced options > Move to C: fails with 0x80073CF6, and the deployment log gives the inner reason:

Authorization of capabilities for Claude_<version>_x64__<pubid> failed with error code 0x800701C5

The package is SignatureKind: Developer, and re-authorizing its capabilities on a new volume appears not to be possible. A Store-signed package on the same volume may behave differently.

What worked: Set-AppxDefaultVolume -Volume "C:\Program Files\WindowsApps", then uninstall and reinstall. The package then lands as a real directory on the system volume, reported and resolved paths match, and the signature check passes.

Side effect worth noting: this also fixed the chrome-native-host.exe / smol-bin.x64.vhdx copy failures ("The specified file could not be encrypted"). Package folders on the secondary volume carried the EFS Encrypted attribute; the system-volume install does not. Related: #25814, #29862.

Bug 2 — bundle path handed to the service is the MSIX-virtualized one

With bug 1 fixed, the VM finally attempted to start, and failed differently:

[VM:start] Beginning startup, bundlePath=<D>:\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
[VM:start] smol-bin.x64.vhdx copied successfully
[VM:start] Configuring Windows VM service...
[VM:start] Startup failed: Error: failed to set VHDX path: VHDX file not found:
  C:\Users\<user>\AppData\Local\Packages\Claude_<pubid>\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx

The app unpacks the bundle to the real redirected %APPDATA% path and logs it as such, but the path it passes to the service is the MSIX-virtualized LocalCache\Roaming\... one. On this machine that directory does not exist at all — LocalCache\Roaming was never created — so the service finds nothing. This reproduces whenever %APPDATA% is redirected away from the default location, which is a supported Windows profile configuration.

Workaround that works and survives updates: make the path the service wants the real directory, and the path the app writes to a junction pointing at it — i.e. the inverse of the obvious fix.

C:\Users\<user>\AppData\Local\Packages\Claude_<pubid>\LocalCache\Roaming\Claude\vm_bundles   <- real directory (bundle lives here)
<D>:\<user>\AppData\Roaming\Claude\vm_bundles  ->  junction to the above

The direction matters. A link on the service side is refused — consistent with #56542, where the service will not open symlinks or junctions — but a link on the app side is fine, because the app does not inspect reparse points and the path the service opens is then link-free at every level. Unlike the copy-based workaround in #56542, nothing has to be redone after each update, as long as the app does not recreate vm_bundles as a real directory.

After that, device_bash works.

Suggested fixes

1. Resolve both paths to their final targets before comparing them in the client signature check, or authenticate on package identity rather than a path string.
2. Have the app pass the real, resolved bundle path to the service — or resolve it service-side — rather than the container-virtualized path. The app already logs the correct path one line earlier.
3. Log the signature rejection service-side. Today the service logs Client connected with no hint, and the only record of the real cause is in %LOCALAPPDATA%\Claude\logs\cowork_vm_node.log, which nothing points users to.
4. For bug 2, the mismatch between the logged bundlePath and the path sent to the service is visible in a single log file; a startup assertion comparing them would turn this into an immediate error message.

Environment

Windows 11 25H2 26200.9457, Claude desktop 2.2553.1 (MSIX), x64, apps installed to a secondary drive, %APPDATA% redirected to that drive, WSL 2.7.14.0 healthy throughout.