Cowork VM: HCS 0x800701c0 Construct failure when Windows "Containers" feature is enabled (MSIX, Win11 25H2)

Resolved 💬 3 comments Opened Mar 21, 2026 by Jamesjhf1 Closed Mar 25, 2026

Environment

  • OS: Windows 11 Pro 25H2 (Build 26200.5516)
  • Claude Desktop: v1.1.7714.0 (MSIX / Microsoft Store)
  • CPU: AMD Ryzen 9 9950X (virtualization enabled in BIOS)
  • Hyper-V: Enabled, all services running (vmcompute, vmms, hns)
  • WSL2: Working (docker-desktop distro runs fine)

Bug Description

Cowork VM fails during HCS Construct phase with HRESULT 0x800701c0 (-2147024448) on Windows 11 Pro 25H2 Build 26200 when the Containers Windows optional feature is enabled.

Error

HCS operation failed: failed to create compute system:
HcsWaitForOperationResult failed with HRESULT 0x800701c0:
{"Error":-2147024448,"ErrorMessage":"","Attribution":[{"OperationFailure":{"Detail":"Construct"}}]}

Root Cause

The Windows optional feature Containers (dism /online /get-featureinfo /featurename:Containers) changes HCS behavior for utility VM construction. When enabled, HcsCreateComputeSystem returns hr=0x0 (success) but HcsWaitForOperationResult returns 0x800701c0 during the async Construct phase.

An identical machine (same hardware, same Windows build, same Claude Desktop version) with Containers disabled runs Cowork successfully.

Fix / Workaround

From an elevated command prompt:

dism /online /disable-feature /featurename:Containers /norestart

Then reboot. Cowork starts successfully after disabling Containers.

Note: Users with Docker Desktop installed may have Containers enabled. Docker Desktop itself does NOT require the Containers feature — it uses WSL2 backend which only needs VirtualMachinePlatform and Microsoft-Hyper-V.

Comparison (two identical machines)

| | Working (SENTINEL) | Failing (IRON-PATRIOT) |
|---|---|---|
| Windows Build | 26200.5516 | 26200.5516 |
| Claude Desktop | 1.1.7714.0 MSIX | 1.1.7714.0 MSIX |
| Microsoft-Hyper-V | Enabled | Enabled |
| VirtualMachinePlatform | Enabled | Enabled |
| Containers | Disabled | Enabled |
| HypervisorPlatform | Disabled | Enabled |
| Cowork | Works | Fails (0x800701c0) |

Additional MSIX VFS Issue

A secondary issue compounds this: the MSIX package causes %APPDATA%\Claude to resolve to ...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ instead of C:\Users\<user>\AppData\Roaming\Claude\. The Electron app sends these MSIX-virtualized paths to cowork-svc.exe, which passes them to HCS. Even when the VHDXs exist at these paths (via hard links), HCS rejects them during Construct.

The previous working version (v1.1.4498.0, Feb 2026) used real AppData\Roaming\Claude paths and worked correctly.

Service Log Excerpt

[Server] Configuring VM for user=james userDataDir=C:\Users\james\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude
[Server]   VHDX: C:\Users\james\AppData\Local\Packages\...\rootfs.vhdx
[HCS] HcsCreateComputeSystem returned: hr=0x0, handle=..., lastErr=The operation completed successfully.
[HCS] HcsWaitForOperationResult returned: hr=0x800701c0
[HCS] Result JSON: {"Error":-2147024448,"ErrorMessage":"","Attribution":[{"OperationFailure":{"Detail":"Construct"}}]}

Related Issues

  • #25914 — CoworkVMService crashes on Build 26200
  • #29657 — VM bundle empty (rootfs.vhdx/sessiondata.vhdx missing)
  • #32088 — smol-bin.vhdx never downloaded
  • #30584 — EXDEV cross-device link in MSIX sandbox

Suggested Fixes

  1. Pre-flight check: Detect if Containers feature is enabled and warn the user or adjust HCS config accordingly
  2. MSIX path resolution: Resolve MSIX-virtualized paths to real filesystem paths before passing to HCS (the service runs as SYSTEM outside the MSIX sandbox)
  3. Documentation: Note that the Containers Windows feature is incompatible with Cowork VM construction

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗