Cowork VM fails on Windows 11 Home: wrong DNS config, missing sessiondata.vhdx, no NAT

Full cowork_vm_node.log

<details>
<summary>Click to expand (929 lines)</summary>

$(cat "$APPDATA/Claude/logs/cowork_vm_node.log")

</details>

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/24918
2. https://github.com/anthropics/claude-code/issues/24945

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[BUG] Cowork Windows — VM fails with "sandbox-helper: failed to unmount host share (tried both virtiofs and Plan9): invalid argument"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

Environment

• OS: Windows 11 (latest build)
• Claude Desktop: Latest version (downloaded fresh Feb 12, 2026)
• Subscription: Max ($200/month)
• First-time Cowork user — never had a previously working setup

What's Wrong

Cowork workspace fails to start. After multiple rounds of troubleshooting, the final error is:

This task didn't load properly
CLI output was not valid JSON. This may indicate an error during startup.
Output: sandbox-helper: failed to unmount host share (tried both virtiofs and Plan9): invalid argument

This replaced an earlier "VM service not running" error after enabling Hyper-V (see troubleshooting steps below).

Expected Behavior

Cowork workspace should boot, connect to the Claude API, and allow task execution — including plugin installation (Legal plugin).

Steps to Reproduce

1. Fresh install of Claude Desktop on Windows 11
2. Sign in with Max subscription
3. Switch to Cowork tab
4. Workspace fails immediately

Troubleshooting Already Attempted

All of these were tried in order. None resolved the issue.

1. Disabled IPVanish VPN adapters

• IPVanish was installed but not running
• Two adapters were visible in Network Connections: "IPVanish" (WAN Miniport IKEv2, Disconnected) and "Local Area Connection" (IPVanish Tap Adapter, Network cable unplugged)
• Both were disabled via right-click → Disable in ncpa.cpl
• Result: Error changed from "Can't reach the Claude API from Claude's workspace" to "VM service not running. The service failed to start." — partial progress but not resolved

2. Restarted Claude Desktop (multiple times)

• Full quit and relaunch, not just minimize
• Result: No change

3. Restarted computer (multiple times)

• Full Windows restart between troubleshooting steps
• Result: No change

4. Reinstalled Claude Desktop

• Uninstalled Claude Desktop completely, then reinstalled from claude.ai/download
• Result: No change

5. Enabled Hyper-V and related Windows features

• Opened "Turn Windows features on or off"
• Enabled: Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform
• These were all previously unchecked/off
• Restarted computer after enabling
• Result: Error changed from "VM service not running" to the current sandbox-helper/virtiofs/Plan9 error — the VM now attempts to start but fails during host share mounting

6. Confirmed network is fine

• Not on VPN (IPVanish adapters now disabled)
• Not on corporate network — personal home Wi-Fi
• Internet working normally for all other applications
• Active adapters after cleanup: Wi-Fi (Intel Wi-Fi 7 BE200), vEthernet (cowork-vm-nat), Bluetooth (not connected)

What Was NOT Tried

• Deleting vm_bundles from %AppData%\Claude and %LocalAppData%\Claude (ran out of patience after 5 rounds of troubleshooting)
• "Reinstall the workspace" link in the error UI (was available at the "VM service not running" stage but error changed before attempting)

Related Issues

This appears related to the cluster of Windows Cowork VM bugs reported this week:

• #24962 — Wrong DNS config, missing sessiondata.vhdx, no NAT
• #24945 — VM boots but API unreachable on Windows
• #25088 — VM gets wrong DNS server
• #25144 — DNS from disconnected adapter
• #25136 — yukonSilver marked as unsupported
• #24070 — VM fails to boot after auto-update (macOS, but similar corrupted VM bundle pattern)

Additional Context

The error progression suggests the VM infrastructure is partially working but the sandbox file-sharing layer (virtiofs/Plan9) is broken:

1. Initial state: Hyper-V not enabled → "VM service not running"
2. After enabling Hyper-V: VM starts → sandbox crashes on host share mount → "failed to unmount host share (tried both virtiofs and Plan9): invalid argument"

This is a fresh Windows 11 machine with no prior VM/container tooling installed. The only complicating factor was IPVanish VPN (installed but not running), whose adapters have since been disabled.

Issue 3: EFS encryption on claudevm.bundle folder prevents smol-bin.vhdx copy and VM boot

Environment: Windows 11, Claude Desktop 1.1.2685.0 (Microsoft Store), Max plan

The app creates the claudevm.bundle folder with the EFS encryption attribute set. Running cipher on the folder shows: "New files added to this directory will be encrypted" — even though the parent folders (Claude\, vm_bundles\) do not have this attribute. The app itself is setting it.

This causes two failures:

1. The copyfile from WindowsApps\...\smol-bin.vhdx into the bundle folder fails with "unknown error" because the destination inherits the encryption attribute, and the MSIX-sandboxed copy operation can't encrypt the file.

1. Even after manually copying smol-bin.vhdx into the folder via robocopy /COPY:D, Hyper-V cannot open it because it gets encrypted on arrival. HCS fails with HRESULT 0x80071772: "The specified file is encrypted and the user does not have the ability to decrypt it."

Workaround (partial): After each failed setup attempt, without restarting Claude:

cipher /d "...\claudevm.bundle"
cipher /d /s:"...\claudevm.bundle"
robocopy "...\app\resources" "...\claudevm.bundle" smol-bin.vhdx /COPY:D
cipher /d "...\claudevm.bundle\smol-bin.vhdx"

Plus manually creating sessiondata.vhdx via diskpart. However the app deletes smol-bin.vhdx on restart and re-applies the encryption attribute to the folder on each retry, making this unsustainable.

Root cause: The app is creating the bundle directory with the EFS encryption flag. This may not reproduce on all systems — it likely depends on a Windows policy or user profile configuration that triggers EFS inheritance for new folders created by MSIX-packaged apps.

Issue 5: EFS encryption on claudevm.bundle folder prevents smol-bin.vhdx copy and VM boot

Environment: Windows 11, Claude Desktop 1.1.2998.0 (Microsoft Store, updated today), Max plan

Still broken on the latest release (v1.1.2998.0). The version changed from 1.1.2685.0 but the error is identical.

The app creates the claudevm.bundle folder with the EFS encryption attribute set. Running cipher on the folder shows: "New files added to this directory will be encrypted" — even though the parent folders (Claude\, vm_bundles\) do not have this attribute. The app itself is setting it.

This causes two failures:

1. The copyfile from WindowsApps\...\smol-bin.vhdx into the bundle folder fails with "unknown error" because the destination inherits the encryption attribute.

1. Even after manually copying smol-bin.vhdx via robocopy /COPY:D, Hyper-V cannot open it because it gets encrypted on arrival. HCS fails with HRESULT 0x80071772: "The specified file is encrypted and the user does not have the ability to decrypt it."

Workaround (partial, not sustainable): After each failed setup, without restarting Claude:

cipher /d "...\claudevm.bundle"
cipher /d /s:"...\claudevm.bundle"
robocopy "...\app\resources" "...\claudevm.bundle" smol-bin.vhdx /COPY:D
cipher /d "...\claudevm.bundle\smol-bin.vhdx"

Plus manually creating sessiondata.vhdx via diskpart. However the app deletes smol-bin.vhdx on restart and re-applies the encryption attribute on each retry.

This may not reproduce on all systems — it likely depends on a Windows policy or user profile configuration that triggers EFS inheritance for new folders created by MSIX-packaged apps.

Update: Still broken on v1.1.3189.0 (14 Feb 2026). Same EFS encryption error, but the source filename has changed from smol-bin.vhdx to smol-bin.x64.vhdx, suggesting architecture-specific builds were added. The copy still fails identically. That's three consecutive releases without a fix (1.1.2685.0 → 1.1.2998.0 → 1.1.3189.0).

Still broken on v1.1.3363.0 (22 Feb 2026). Same EFS encryption error on smol-bin.x64.vhdx copy. That's four consecutive releases now (1.1.2685.0 → 1.1.2998.0 → 1.1.3189.0 → 1.1.3363.0). Note that #24974 has been merged into this issue.

Update 3: v1.1.3963.0 (25 Feb 2026) — still broken. Five consecutive releases with the same EFS encryption error on smol-bin.x64.vhdx copy. Is anyone at Anthropic able to reproduce this or investigate the EFS attribute being set on the claudevm.bundle folder?

Bug seems to be fixed on Claude 1.1.4328 (d8e391). I am able to use Cowork without any issue

Networking issues like this were fixed in v1.1.4328

Leaving this open to track EFS which is proving hard to reproduce internally

Update 4: v1.1.4173.0 (1 Mar 2026) — still broken. Six consecutive releases with the same EFS encryption error on the smol-bin.x64.vhdx copy. This has been unfixed for nearly three weeks now.

Was working just fine till yesterday and now getting constant messages that VM Service is not available. What gives?

Update 6: v1.1.8359.0 (24 Mar 2026) — EFS copy issue is now fixed. smol-bin.x64.vhdx copies successfully. sessiondata.vhdx still not auto-created.

New blocker: CoworkVMService crashes immediately with "signature verification initialization failed: failed to get service executable path: The system cannot find the path specified."

The HCS and HCN layers initialize fine — the crash occurs when the service tries to verify its own executable signature.

The registered service path (C:\Program Files\WindowsApps\Claude_1.1.8359.0_x64__...\app\resources\cowork-svc.exe) exists and is accessible, but the service's internal path resolution fails.

Detailed log at C:\ProgramData\Claude\Logs\cowork-service.log shows HCS and HCN initializing successfully before the signature verification failure.

Update 7: Workaround for "signature verification initialization failed: failed to get service executable path"

After resolving the EFS encryption blocker (documented in my earlier comments), the next failure was CoworkVMService crashing immediately on startup with:

signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

The cowork-service.log showed HCS and HCN initializing successfully before the crash. The root cause appears to be MSIX path resolution — the service process running under the Service Control Manager cannot resolve its own executable path within the WindowsApps directory, likely due to the conditional ACE requiring a WIN://SYSAPPID token attribute that SCM-launched services don't carry.

Workaround: Copy cowork-svc.exe out of the WindowsApps directory and run it interactively from an elevated prompt:

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
copy "C:\Program Files\WindowsApps\Claude_1.1.XXXX.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe" "C:\Temp\cowork-svc.exe"
C:\Temp\cowork-svc.exe

(Replace XXXX with your version — find it via Get-AppxPackage -Name *Claude* | Select-Object InstallLocation)

When run interactively, the binary enters debug mode and sets signature verification to Enforce: false. The service starts successfully, HCS/HCN initialize, the named pipe server listens, and Claude Desktop connects. The console window must stay open.

Important notes:

• Do NOT manually create an HNS network or NAT — the service manages its own networking. If you previously created a "cowork-vm-nat" network manually, the service will clean it up on startup.
• After a Claude Desktop auto-update, re-copy cowork-svc.exe from the new version's install directory.
• An initial "Request timed out: addApprovedOauthToken" error may appear on the first attempt. Restarting the interactive service (Ctrl+C, then relaunch) resolves it.

Tested on Windows 11 Pro, v1.1.8359.0. Cowork fully functional with this workaround. Related issues: #29941, #32481.

Update 7: Interactive workaround confirmed working, including on the new v1.19367.0.0 build

Following on from the EFS work documented above, the next and current blocker is that CoworkVMService (cowork-svc.exe) will not start in normal Windows service mode. Started by the SCM it crashes immediately with:

signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

The cowork-service.log shows HCS and HCN initializing successfully before the crash. The root cause appears to be MSIX path resolution: an SCM-launched service (running as LocalSystem) cannot resolve the path to its own executable inside C:\Program Files\WindowsApps, likely because it lacks the WIN://SYSAPPID token attribute that the conditional ACE on that directory requires. This is consistent with the reports on #29941, #32481, and #37070.

Workaround. Run cowork-svc.exe interactively from an elevated prompt instead of as a service. It must first be copied out of WindowsApps (the same ACE blocks direct execution). In an elevated PowerShell:

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
copy "C:\Program Files\WindowsApps\Claude_<VERSION>_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe" "C:\Temp\cowork-svc.exe"
& "C:\Temp\cowork-svc.exe"

(Find <VERSION> via Get-AppxPackage -Name Claude | Select-Object InstallLocation.)

Run this way, the binary logs "interactive/debug mode", sets signature verification to Enforce: false, starts the named pipe server, and Claude Desktop connects. The VM then boots fully: sessiondata.vhdx is auto-created, the compute system starts, network reaches CONNECTED, and the guest reports "sdk-daemon is ready". Cowork works normally after that.

Confirmed on v1.19367.0.0. After this build auto-updated (note the version format changed from 1.1.XXXX.0), service mode still crashes identically, but the interactive workaround still works. One migration note: the update landing while the previous interactive binary was still running corrupted the VM bundle mid-setup (EPERM rename on rootfs.vhdx.tmp, with vmwp.exe holding the VHDX locked). Recovery was: quit Claude, stop vmcompute, kill vmwp, delete the claudevm.bundle folder, restart vmcompute, then reapply the workaround with the fresh binary.

Caveats.

• The console window is effectively the service. Closing it kills cowork-svc.exe and Cowork stops. It has to stay open for the whole session.
• Mapped network drives (in my case O, S, V) fail to mount into the VM as Plan9 shares, each stalling ~10s then failing with HRESULT 0x80370118 and being skipped as optional. Local drives (C, D, G) mount fine. The serial network-drive timeouts appear to be what triggers the app's "Request timed out: startVM" banner even though the VM has actually started.
• The per-request Authenticode verification overhead in #31848 still applies, so this workaround runs with continuous CPU cost.

A proper fix for service-mode startup (so the interactive window and its CPU overhead aren't needed) would be the real resolution here.