[Cowork] VM spawn succeeds but stdin pipe dies after 4 seconds on Windows 11 25H2 (Build 26200)

Environment

• OS: Windows 11 Pro Build 26200 (25H2)
• Claude Desktop: 1.1.4173.0 (MSIX from Windows Store)
• SDK: 2.1.51
• Bundle: fb30784dadb34104626c8cf6d8f90dd47cd393cc
• GPU: AMD Radeon RX 7800 XT (Driver 32.0.23017.1001, 2026-01-08)
• CPU: AMD (MCE events detected - see below)
• Security: Bitdefender Internet Security (ruled out as cause)
• Hyper-V Features: HypervisorPlatform, VirtualMachinePlatform, Containers all enabled
• WSL2: Installed (docker-desktop distro, stopped)

Bug Description

Cowork VM starts successfully, SDK installs, process spawn succeeds (~1000ms), but exactly ~4 seconds after spawn, the stdin pipe connection dies with WSAECONNRESET (error 10054). The VM remains connected and API remains reachable.

Same version (1.1.4173.0) worked on Feb 17, 2026. No Windows Updates between Feb 17-25.

Exact Error Pattern (from cowork_vm_node.log)

[Startup] version=1.1.4173.0 
[Startup] vm_bundle: fb30784dadb34104
[VM] Starting VM (took 10989ms)
[VM] Installing SDK 2.1.51
[VM] Copying smol-bin.x64.vhdx
[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
[Spawn:vm] Spawn succeeded in 1000ms
  → exactly 4 seconds later →
[Process] failed to write stdin: Error: sdk-daemon not connected
[CoworkVMProcess] kill failed with error: Error: sdk-daemon not connected

This pattern repeats identically across every attempt:

• Spawn 1: succeeded in 1000ms → 4s → stdin dead
• Spawn 2: succeeded in 1209ms → 4s → stdin dead
• Spawn 3: succeeded in 898ms → 4s → stdin dead

What Works

• VM startup (10989ms)
• SDK 2.1.51 installation
• smol-bin.x64.vhdx copy
• Network connection (CONNECTED)
• API reachability (REACHABLE)
• Process spawn (succeeds in ~900-1200ms)
• OAuth token approved with MITM proxy

What Fails

• stdin pipe communication dies ~4 seconds after spawn
• Error: WSAECONNRESET / "sdk-daemon not connected"
• Identical behavior across all attempts

Comparison: When It Worked (Feb 17)

Same version, same startup sequence. Spawn succeeded and ran for 50358ms before normal SIGTERM exit. The 4-second death pattern did not exist.

Potential Correlation: CPU MCE (Machine Check Exception) Events

Investigation revealed the system experienced CPU hardware errors (NOT GPU as initially suspected) that correlate with the Cowork failure timeline:

MCE Events Found (WHEA)

| Date | Time | Type | CPU Core |
|------|------|------|----------|
| 2026-02-16 | 09:14:24 | Cache Hierarchy Error | APIC ID 1 |
| 2026-02-24 | 20:29:17 | Cache Hierarchy Error | APIC ID 19 |

Timeline Correlation

• Feb 16: MCE crash on APIC 1
• Feb 17: Cowork still worked (last successful session, spawn ran 50+ seconds)
• Feb 24: MCE crash on APIC 19
• Feb 25: Cowork broken (stdin pipe dies after 4 seconds)

System Crash Pattern (user-reported)

• 3 months completely stable
• 2 weeks of frequent crashes (~10/day)
• 6 weeks completely stable
• 2 days of crashes (current episode, Feb 24-25)
• Same hardware, same software throughout

Hypothesis

MCE events may corrupt Hyper-V internal state (page tables, VM bus channels, or named pipe infrastructure). The VM starts and network works, but the low-level stdin/stdout pipe communication pathway is damaged. This would explain why:

• Nuclear reset (deleting all bundles + fresh download) didn't help
• The VM appears healthy (network connected, API reachable)
• Only the stdin pipe communication fails

Troubleshooting Performed (All Failed)

| # | Action | Result |
|---|--------|--------|
| 1 | OS Reboot (shutdown /r /t 0) | No effect |
| 2 | sessiondata.vhdx deletion | File didn't exist |
| 3 | Nuclear Reset (deleted all vm_bundles, HNS cleanup, service restarts, fresh download ~11.71 GB) | Same error after re-download |
| 4 | Bitdefender disabled (Virenschutz + Erweiterte Gefahrenabwehr + Firewall all OFF) | Same error |
| 5 | HypervisorPlatform verification (all features enabled, all services running, zero Event Log errors) | All OK but Cowork still broken |
| 6 | .wslconfig fix (networkingMode=mirrored removed) | No effect |
| 7 | WSL shutdown | No effect |
| 8 | GPU/Crash investigation | Found MCE events, no GPU errors |

Enhanced Monitoring Results

Named Pipe monitoring during failure:

• Only 1 pipe found: cowork-vm-service
• 0 TCP connections from CoworkVMService
• VM processes running: vmcompute.exe, vmwp.exe, vmms.exe
• HNS Endpoint active: cowork-vm-eth0, State=2, IP=172.16.0.86

Services Status (all Running)

• CoworkVMService
• HvHost
• vmcompute
• vmms
• hns (Host Networking Service)

Windows Updates in Timeframe

• KB5077181 (Security Update, 2026-02-14)
• KB5077869 (Security Update, 2026-02-12)

Event Log Summary (Feb 17-25)

• 304 DCOM errors (DistributedCOM)
• 65 BTHUSB errors (Bluetooth)
• 51 TPM-WMI errors
• 2 WHEA MCE events (the critical ones)
• 0 GPU/display errors
• 0 LiveKernelReports
• 0 Minidumps

Questions for Developers

1. Does Cowork use any state that persists across VM restarts beyond what's in vm_bundles?
2. Could a Hyper-V VM bus channel corruption survive a bundle reset?
3. Is there a way to force-reset the stdin/stdout pipe infrastructure specifically?
4. The 4-second timeout is very consistent - is this a hardcoded timeout in the sdk-daemon connection logic?

Related Issues

#25096, #25132