[BUG] Cowork Windows — hvsock dies after idle, "connection aborted by software in host machine" (Win 11 Pro 24H2)

Preflight Checklist

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

What's Wrong?

Summary

Cowork on Windows 11 Pro 24H2 (Build 26100.7840) suffers from intermittent hvsock socket death. The Hyper-V socket between Claude Desktop and the VM drops ~4-11 seconds after session spawn, especially after idle periods (>15 min). During active use, sessions run stable (100% success rate over 30+ consecutive sessions). After idle, the first session fails ~50% of the time.

This is the single remaining bug after resolving 16 other issues through extensive debugging over 3 days.

Error messages:

• failed to write data: An established connection was aborted by the software in your host machine
• sdk-daemon not connected
• This task didn't load properly

Environment

| Component | Value |
|-----------|-------|
| OS | Windows 11 Pro 24H2 Build 26100.7840 (stable release) |
| CPU | Intel i7-12700KF |
| RAM | 128 GB |
| Claude Desktop | v1.1.4010.0 (MSIX) — also tested on v1.1.2998, v1.1.3189 |
| Node.js | v22.15.1 |
| Hyper-V | Enabled (all features) |
| VPN/Proxy | None |
| Antivirus | Windows Defender only |
| Docker | Uninstalled (removed to eliminate interference) |
| Plan | Max |

Reproduction Steps

1. Open Claude Desktop on Windows 11 Pro 24H2
2. Start a Cowork session — works fine
3. Complete several tasks — all successful
4. Wait 15+ minutes (idle, no interaction)
5. Start a new Cowork task
6. Result: ~50% chance of failed to write data: An established connection was aborted by the software in your host machine within 4-11 seconds

During active use (no idle gaps): 30+ sessions in a row succeed, 100% success rate.

Log Evidence

Successful session (active use):

[Spawn:vm] Spawn succeeded in 1.2s
[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
[Session runs 6-13+ minutes, completes tasks successfully]

Failed session (after idle):

[Spawn:vm] Spawn succeeded in 1.1s
[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
[Process:...] failed to write data: An established connection was aborted by the software in your host machine
[Process:...] sdk-daemon not connected
← Socket dies ~4-11 seconds after spawn, despite network being CONNECTED and API being REACHABLE

Idle correlation data (23 Feb, after VM reinstall):

| Time | Idle before | Result |
|------|-------------|--------|
| 18:02 | 2 min (VM restart) | Socket dead after 7s |
| 18:33-19:11 | 15-45s between sessions | 30+ sessions ALL successful |
| 21:19 | ~2 hours idle | Socket dead after 6s |
| 21:36 | 17 min idle | Socket dead after 7s |
| 22:18 | 40 min idle | Socket dead after 8s |

AxiosErrors on startup (debug log):

15:21:28.792 [ERROR] AxiosError: Error (at request, B:/~BUN/root/claude.exe:95:2149)
15:21:29.140 [ERROR] AxiosError: Error
15:21:29.152 [ERROR] AxiosError: Error
15:21:29.172 [ERROR] AxiosError: Error
15:21:29.176 [ERROR] AxiosError: Error
← 8 AxiosErrors within 400ms at every startup, causes "Could not load connectors directory"

What I've already eliminated (extensive debugging over 3 days)

Fixed issues (not the cause):

| # | Issue | Fix applied | Result |
|---|-------|-------------|--------|
| 1 | Windows Build 26200 (25H2 Preview) — Kernel Watchdog crashes | Downgraded to Build 26100 (24H2 stable) | Crashes gone, hvsock issue remains |
| 2 | Missing DNS on cowork-vm-vnet adapter | Set DNS to 192.168.0.1 + 1.1.1.1 | DNS works, hvsock issue remains |
| 3 | NAT subnet mismatch (172.16 vs 172.17) | Now managed internally via ICS | NAT works, hvsock issue remains |
| 4 | Docker Desktop interference | Completely uninstalled Docker + WSL distros | No change |
| 5 | VirtioFS mount failure (spaces in path) | Renamed folders, no spaces | Mounts work, hvsock issue remains |
| 6 | P9RdrService stopping | Set to Automatic via registry | Service stable, hvsock issue remains |
| 7 | Developer Mode + Sideloading active | Disabled both | No change |
| 8 | Monitor-Off after 15min | Set to Never | Reduced frequency but didn't eliminate |
| 9 | Screensaver active | Disabled | No change |
| 10 | TCP KeepAlive default (2h) | Tested with 60s — reverted (caused AxiosErrors) | No effect on hvsock |
| 11 | USB Selective Suspend | Disabled | No change |
| 12 | Processor Min State | Set to 100% | No change |
| 13 | HungAppTimeout 5s | Increased to 30s | No change on hvsock |
| 14 | Container features disabled | Enabled Containers, Containers-HNS, DisposableClientVM | Service starts, hvsock issue remains |
| 15 | Claude Desktop version | Updated from v1.1.2998 to v1.1.4010 | No change |
| 16 | Firewall blocking | Claude + Hyper-V allowed inbound + outbound | Already open, not the cause |

Network diagnostics at time of failure:

Primary adapter:     Ethernet 2, 192.168.0.196, Metric 25, Connected
Cowork adapter:      vEthernet (cowork-vm-vnet), 172.16.0.1, Metric 5000, Connected
DNS:                 192.168.0.1 + 1.1.1.1 (configured)
API test:            api.anthropic.com:443 TcpTestSucceeded=True
VM Network status:   CONNECTED
VM API reachability: REACHABLE
← Everything is connected. The hvsock just dies anyway.

Services at time of failure (all running):

CoworkVMService   Running   Automatic
vmcompute         Running   Automatic
vmms              Running   Automatic
WinNat            Running   Automatic
SharedAccess      Running   Manual (trigger-started by CoworkVMService)

Analysis

The hvsock (Hyper-V socket AF_HYPERV) between Claude Desktop and the Cowork VM is being terminated by Windows after idle periods. This is not a network issue — TCP connectivity to Anthropic's API works fine from both host and VM. The socket is killed at the Winsock/kernel level (WSAECONNABORTED / error 10053), before any network routing is involved.

Key evidence that this is an hvsock-specific issue:

1. Network is CONNECTED and API is REACHABLE at the exact moment the socket dies
2. Only hvsock connections are affected — regular HTTPS connections work fine
3. The pattern correlates with Windows idle/power states, not network events
4. TCP KeepAlive changes have zero effect (hvsock is AF_HYPERV, not AF_INET)
5. 128 GB RAM, i7-12700KF — not a resource issue

Related closed issues

• #25516 — v1.1.2998.0 severe instability (closed by bot)
• #25876 — ECONNRESET on Win 11 Pro 24H2 (closed by bot)
• #24918 — Cannot connect to API on Win 11 Home (closed by bot)
• #25308 — VM starts but API unreachable (closed by bot)
• #26510 — Connection aborted errors
• #26873 — Plan9 mount failed: bad address
• #27010, #27363 — VM service issues

Note: Multiple issues reporting the same core problem have been auto-closed by the GitHub Actions bot as "not related to Claude Code." This hvsock instability IS a Claude Desktop/Cowork infrastructure issue that affects Windows users specifically.

Impact

• Cowork is unusable for async workflows — any pause >15 min kills the session
• Session recovery requires full restart of Claude Desktop
• Work in progress is lost when the socket dies mid-task
• Paying Max plan customer with no reliable workaround

Expected behavior

hvsock connection should survive idle periods and maintain stable communication between Claude Desktop and the Cowork VM for the duration of a session.

Workaround (current)

Start a new Cowork session after failure (mostly with app restart). Second attempt usually succeeds. Keep sessions active (no long idle gaps) to maintain stability.

What Should Happen?

hvsock connection should survive idle periods (15+ minutes) and maintain stable communication between Claude Desktop and the Cowork VM for the duration of a session. During active use, 30+ sessions succeed in a row with 100% success rate — only idle periods kill the socket. The connection should not be terminated by Windows power management or Hyper-V socket cleanup.

Error Messages/Logs

# Error 1 (most common):
failed to write data: An established connection was aborted by the software in your host machine

# Error 2 (same root cause):
sdk-daemon not connected

# From cowork_vm_node.log (failed session after idle):
[Spawn:vm] Spawn succeeded in 1.1s
[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
[Process] failed to write data: An established connection was aborted by the software in your host machine
[Process] sdk-daemon not connected
# ← Socket dies 4-11 seconds after spawn, despite network CONNECTED and API REACHABLE

# From Claude Code debug log (startup AxiosErrors causing "Could not load connectors directory"):
15:21:28.792 [ERROR] AxiosError: Error (at request, B:/~BUN/root/claude.exe:95:2149)
15:21:29.140 [ERROR] AxiosError: Error
15:21:29.152 [ERROR] AxiosError: Error
15:21:29.172 [ERROR] AxiosError: Error
# ← 8 AxiosErrors within 400ms at every startup

Steps to Reproduce

1. Open Claude Desktop (v1.1.4010) on Windows 11 Pro 24H2 (Build 26100.7840) with Hyper-V enabled
2. Start a Cowork session — it works fine
3. Complete 2-3 tasks successfully (confirming Cowork is functional)
4. Wait 15+ minutes without interacting (idle)
5. Start a new Cowork task
6. Result: ~50% chance the task fails within 4-11 seconds with "failed to write data: An established connection was aborted by the software in your host machine"

Key observation: During active use with no idle gaps, 30+ consecutive sessions succeed (100% success rate). The bug ONLY triggers after idle periods.

System: i7-12700KF, 128 GB RAM, no VPN, no Docker, Windows Defender only, all Hyper-V features enabled. 16 other potential causes have been systematically eliminated (see full list in description).

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is a Claude Desktop (Cowork) issue, not Claude Code CLI. Claude Desktop v1.1.4010.0 (MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

N/A — Cowork runs in Hyper-V VM, not terminal
This bug has been extensively debugged over 3 days. 16 other potential causes were systematically eliminated:

ELIMINATED: Windows Build 26200 kernel watchdog (downgraded to 26100), missing DNS on cowork adapter, NAT subnet mismatch, Docker interference (uninstalled), VirtioFS spaces in path (renamed folders), P9RdrService stopping (set to Automatic), Developer Mode active (disabled), Monitor-Off 15min (set to Never), Screensaver (disabled), TCP KeepAlive 60s (reverted — no effect on hvsock which is AF_HYPERV not AF_INET), USB Selective Suspend (disabled), Processor Min State (set to 100%), HungAppTimeout (increased to 30s), Container features (enabled), Claude Desktop version (updated to latest), Firewall (Claude + Hyper-V allowed).

The ONLY remaining issue is the hvsock socket dying after idle. Network is CONNECTED, API is REACHABLE — the Hyper-V socket itself is being terminated by Windows.

Related closed issues (all auto-closed by bot, same underlying problem): #25516, #25876, #24918, #25308, #26510, #26873, #27010, #27363