[BUG] [Cowork] Windows: sessiondata.vhdx not created + network diagnostics uses macOS commands

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/24962

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

Can confirm this on Windows 11 Pro 25H2 (Build 26200), Claude Desktop 1.1.2685.0.

Same two issues as described here, plus an additional finding:

Issue 3: sandbox-helper mount failure after manual sessiondata.vhdx fix
After manually creating sessiondata.vhdx via diskpart, the VM boots and connects, but the Claude Code process inside the VM crashes immediately (~399ms) with:

sandbox-helper: failed to unmount host share (tried both virtiofs and Plan9): invalid argument

This suggests the sandbox mount layer also needs Windows-specific handling, not just the diagnostics module.

Full reproduction details and logs in #25275.

Confirming both issues on Windows 10 Pro

Environment:

• OS: Windows 10 Pro 10.0.19045
• Hyper-V: Enabled and functional
• VM Bundle: Complete (rootfs.vhdx, smol-bin.vhdx, vmlinuz, initrd)

---

Issue 1: Missing sessiondata.vhdx — CONFIRMED & manually fixed

Same error as OP:

HCS operation failed: failed to start VM: HcsWaitForOperationResult failed with HRESULT 0x80070002

The sessiondata.vhdx file was never created during bundle setup. Fixed manually with:

New-VHD -Path "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx" -SizeBytes 2GB -Dynamic

Issue 2: macOS network diagnostics on Windows — CONFIRMED

After fixing sessiondata.vhdx, the VM boots but times out after 60 seconds. From cowork_vm_node.log:

[networkDiagnostics] === Comprehensive macOS Diagnostics ===
[networkDiagnostics] Failed to run /sbin/ifconfig: spawn /sbin/ifconfig ENOENT
[networkDiagnostics] Failed to run /usr/sbin/scutil: spawn /usr/sbin/scutil ENOENT
[networkDiagnostics] Failed to run /usr/bin/pgrep: spawn /usr/bin/pgrep ENOENT
[networkDiagnostics] Failed to run /usr/sbin/kextstat: spawn /usr/sbin/kextstat ENOENT
[networkDiagnostics] Failed to run /usr/bin/log: spawn /usr/bin/log ENOENT
[VM:start] Connection timeout, last completed step: load_swift_api
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

The network diagnostics module is running macOS-only commands (/sbin/ifconfig, /usr/sbin/scutil, /usr/sbin/kextstat) on Windows, all failing with ENOENT. This confirms the macOS network initialization code was shipped to Windows without platform-specific adaptation.

Summary

This is a third independent confirmation (after OP on Windows 11 and @Voider1337 on Windows 11 Pro 25H2) — now also reproduced on Windows 10 Pro. The Cowork VM on Windows is fundamentally broken due to missing sessiondata.vhdx creation and macOS-only network diagnostics code.

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.

Same issue here — Windows 11 Pro, Claude 1.1.2998
Confirming the sessiondata.vhdx not created issue. After manually creating it via diskpart, the VM boots but cannot reach the API.
Steps tried:

Enabled full Hyper-V stack (Microsoft-Hyper-V-All)
Manually created sessiondata.vhdx via diskpart
Created NAT: New-NetNat -Name "CoworkNAT" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
Enabled IP forwarding on vEthernet (cowork-vm-nat)
Set DNS to 8.8.8.8/8.8.4.4 on the vEthernet interface
Disabled Windows Firewall and Avira antivirus
Reset HNS networks multiple times

Result: VM boots, SDK installs, but API reachability goes PROBABLY_UNREACHABLE → UNREACHABLE. Logs confirm macOS diagnostics commands (/sbin/ifconfig, /usr/sbin/scutil) being run on Windows. Forwarding and DNS settings do not persist across reboots.

confirm this issue on
Win 11 Home
version 25H2
OS Build 26200.7840

Merging into #24962

Update #3: SOLVED — 192.168.100.0/24 subnet workaround

After four days of troubleshooting, Cowork is now working on Windows 11 Pro (Surface Laptop 4). Sharing the full fix for others hitting this issue.

What Finally Worked

The root cause on my system was that the default 172.16.0.0/24 subnet used by Cowork is ghost-claimed by Windows internally when Hyper-V is enabled. It doesn't show up in Get-NetNat but still blocks NAT creation (returns "duplicate name exists on the network" error). Using an alternate subnet (192.168.100.0/24) avoids the conflict entirely.

Credit to a Reddit post for this insight.

The Fix (Step by Step)

Prerequisites: Windows 11 Pro with Hyper-V enabled. If on Windows 11 Home, upgrade to Pro first ($130 CAD via Settings > System > Activation) and enable Hyper-V via optionalfeatures.

Step 1 — Shut down WSL if installed:

wsl --shutdown

Step 2 — Restart your PC. Open PowerShell as Administrator before opening Claude or anything else.

Step 3 — Find the Cowork network adapter:

Get-NetAdapter | Where-Object {$_.Name -like "*cowork*"}

Note the ifIndex value for the vEthernet (cowork-vm-vnet) adapter (not the CoworkNAT one if you have it).

Step 4 — Assign an IP to the adapter:

New-NetIPAddress -InterfaceIndex YOUR_IFINDEX -IPAddress "192.168.100.1" -PrefixLength 24

Replace YOUR_IFINDEX with your actual ifIndex number.

Step 5 — Create the NAT:

New-NetNat -Name "cowork-vm-nat" -InternalIPInterfaceAddressPrefix "192.168.100.0/24"

Should return Active: True.

Step 6 — Open Claude and go to the Cowork tab. It should connect.

Optional: Clean Rebuild Before Applying Fix

If you've been troubleshooting and have corrupted VM state, do a clean rebuild first:

1. Close Claude completely (system tray > quit)
2. Stop services:

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
Stop-Service vmcompute -Force

1. Delete VM folders:

Remove-Item "$env:APPDATA\Claude\vm_bundles" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:APPDATA\Claude\claude-code-vm" -Recurse -Force -ErrorAction SilentlyContinue

1. Restart services:

Start-Service vmcompute
Start-Service hns
Start-Service CoworkVMService

1. Then apply the IP and NAT fix above before opening Claude.

Note on Persistence

The NAT rule is stored as Store: Local and may not persist across reboots. If Cowork stops working after a restart, re-run Steps 4 and 5. Alternatively, create a scheduled task to run these commands at startup automatically.

What Didn't Work (For Reference)

Over four days, the following were attempted and did NOT resolve the issue on their own:

• Using 172.16.0.0/24 subnet (ghost-claimed by Windows, blocks NAT creation)
• Disabling unused network adapters (Bluetooth, Ethernet)
• Deleting vm_bundles and claude-code-vm multiple times
• Removing and recreating HNS networks
• Manually creating VMSwitch + NAT on 172.16.0.0/24 (Claude ignored it, created ICS network instead)
• Manually creating sessiondata.vhdx (installer bug, file not provisioned)
• Enabling IP forwarding on cowork adapter
• Multiple Claude Desktop updates and workspace reinstalls
• Running on Windows 11 Home (no full Hyper-V, upgrade to Pro was required)

Why 172.16.0.0/24 Doesn't Work

Claude creates its cowork-vm-vnet HNS network as Type: ICS (Internet Connection Sharing) on the 172.16.0.0/24 subnet. On Windows 11 with Hyper-V enabled, this subnet is internally claimed in a ghost state. Get-NetNat returns empty, but New-NetNat throws a duplicate error. The ICS network type cannot route to api.anthropic.com. Switching to 192.168.100.0/24 avoids the ghost claim and allows proper NAT routing.

Environment

• Device: Microsoft Surface Laptop 4
• Processor: AMD Ryzen 7 Microsoft Surface (R) Edition (2.00 GHz), x64
• RAM: 16 GB
• OS: Windows 11 Pro 25H2 (Build 26200.7840)
• Hyper-V: Fully enabled
• Claude Desktop: Latest version (Feb 25, 2026)
• Network: Telus Optik, Ethernet primary, no VPN

Underlying Bugs (Still Present in Claude Desktop)

1. sessiondata.vhdx not created during workspace provisioning. Workspace install/reinstall never generates this file. VM fails with HRESULT 0x80070002 without it.
2. ICS network type on 172.16.0.0/24 cannot route to API. Claude hardcodes ICS type instead of NAT for its HNS network creation on Windows.
3. CoworkVMService doesn't auto-start. Must be manually started after VM folder deletion or service stops.

These should be fixed in Claude Desktop so users don't need manual NAT workarounds.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.