Cowork VM: HCS 0x800701c0 Construct failure when Windows "Containers" feature is enabled (MSIX, Win11 25H2)
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
- Pre-flight check: Detect if
Containersfeature is enabled and warn the user or adjust HCS config accordingly - MSIX path resolution: Resolve MSIX-virtualized paths to real filesystem paths before passing to HCS (the service runs as SYSTEM outside the MSIX sandbox)
- Documentation: Note that the Containers Windows feature is incompatible with Cowork VM construction
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗