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

[MSahinli]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Cowork on Windows fails to start with two distinct issues:

Issue 1: sessiondata.vhdx is never created during VM setup

The VM bundle downloads successfully (100% progress bar), but the sessiondata.vhdx file is never created. The VM then fails to start with:

HCS operation failed: failed to start VM: HcsWaitForOperationResult failed with HRESULT 0x80070002
"Die Anlage C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx wurde aufgrund eines Fehlers nicht gefunden"

The VM bundle directory contains:

initrd              (175 MB)
rootfs.vhdx         (9.4 GB)
smol-bin.vhdx       (37 MB)
vmlinuz             (14 MB)
.initrd.origin
.rootfs.vhdx.origin
.vmlinuz.origin

sessiondata.vhdx is missing. It is never generated during the setup process.

Manually creating the VHD via New-VHD -Path "...\sessiondata.vhdx" -SizeBytes 2GB -Dynamic resolves the missing file error but leads to Issue 2.

Issue 2: Network diagnostics uses macOS commands on Windows

After manually creating the sessiondata.vhdx, the VM boots but times out after 60 seconds. The cowork_vm_node.log reveals that the network diagnostics module is calling macOS-specific binaries on Windows:

[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

The log literally says "Comprehensive macOS Diagnostics" while running on Windows. It appears the macOS network initialization code was shipped to Windows without platform-specific adaptation, which likely causes the VM networking to fail entirely.

What Should Happen?

1. sessiondata.vhdx should be automatically created during the VM bundle setup on Windows (similar to sessiondata.img on macOS).
2. Network diagnostics should use Windows commands (ipconfig, Get-VpnConnection, Get-NetAdapter, etc.) instead of macOS commands (/sbin/ifconfig, /usr/sbin/scutil, /usr/sbin/kextstat).
3. The VM should successfully boot and establish a connection on Windows.

Error Messages/Logs

### Missing sessiondata.vhdx error:

HCS operation failed: failed to start VM: HcsWaitForOperationResult failed with HRESULT 0x80070002:
{"Error":-2147024894,"ErrorMessage":"Das System kann die angegebene Datei nicht finden.",
"ErrorEvents":[{"Message":"Die Anlage C:\Users\Mustafa\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx wurde aufgrund eines Fehlers nicht gefunden"}]}


### macOS commands on Windows (from cowork_vm_node.log):

2026-02-11 12:42:27 [warn] [networkDiagnostics] Failed to detect VPN interfaces: Error: Failed to spawn /sbin/ifconfig: spawn /sbin/ifconfig ENOENT
2026-02-11 12:42:27 [warn] [networkDiagnostics] Failed to detect connected VPNs via scutil: Error: Failed to spawn /usr/sbin/scutil: spawn /usr/sbin/scutil ENOENT
2026-02-11 12:42:27 [info] [networkDiagnostics] === Comprehensive macOS Diagnostics ===
2026-02-11 12:42:27 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds

Steps to Reproduce

1. Install Claude Desktop for Windows (v1.1.2685.0) with Cowork enabled
2. Ensure Hyper-V is enabled and SVM Mode is active in BIOS
3. Open Claude Desktop and switch to the Cowork tab
4. Observe the VM bundle downloading to 100%
5. VM fails to start — sessiondata.vhdx is missing from the bundle directory
6. If sessiondata.vhdx is manually created, VM boots but times out after 60 seconds due to failed network initialization

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

latest

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Troubleshooting steps already performed:

• Deleted and re-downloaded vm_bundles directory multiple times
• Reinstalled Claude Desktop
• Rebooted PC after enabling SVM Mode in BIOS
• Verified Hyper-V is enabled (Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V → State: Enabled)
• Confirmed systeminfo shows "Virtualisierung in Firmware aktiviert: Ja" (after BIOS change)
• Installed Docker Desktop (no effect)
• Manually created sessiondata.vhdx via New-VHD (resolved file-not-found error but led to connection timeout)
• Verified no VPN or proxy interfering

The root cause appears to be that the Windows port of Cowork is incomplete — the VM setup pipeline doesn't create sessiondata.vhdx, and the network diagnostics module still references macOS-only binaries.

[github-actions]

Found 1 possible duplicate issue:

1. Cowork VM fails on Windows 11 Home: wrong DNS config, missing sessiondata.vhdx, no NAT #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

[Voider1337]

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.

[Adolfo41]

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.

[max1000000]

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.

2. 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.