claude-code - 💡(How to fix) Fix [Bug] Windows Crash - CoWork Polling - Unhandled SystemError in network polling causes cascading crash [1 comments, 2 participants]

Bug Description Bug Report: Claude Desktop — Long-Lived CoWork Sessions Cause Cascading Network-Stack Poll Failure on Windows After Sleep/Wake

Summary

When one or more CoWork sessions remain open after completing their work, the Claude desktop app continues polling the Windows network stack on a recurring timer. If the host machine has gone through one or more sleep/wake cycles, the Windows network driver can be left in a corrupted state. In that state, every timer tick throws an unhandled SystemError from Node.js's os.networkInterfaces() call. With multiple stale sessions keeping the timer alive, the error rate escalates to hundreds per hour, eventually degrading system resources enough to cause a desktop crash or forced system restart.

What Caused It

Stage 1 — Session accumulation. The user opened multiple CoWork sessions across different projects. Work in each session eventually completed (or paused), but the sessions were not explicitly closed. Each open session keeps the Claude app's internal session-bridge polling active, including a recurring timer (fires every ~3–6 seconds) that calls os.networkInterfaces() to check host connectivity.

Stage 2 — Network stack corruption via sleep/wake. The machine went to sleep at least twice while sessions remained open. On each wake, Windows restored the network adapter but left residual driver state that causes the low-level interface-enumeration API (GetAdaptersAddresses) to return an error code outside Node.js's known error table.

Stage 3 — Unhandled SystemError storm. After the second or third wake, every poll tick throws: SystemError [ERR_SYSTEM_ERROR]: A system error occurred: undefined returned undefined (undefined) at Object.networkInterfaces (node:os) at <timer callback> (app://.vite/build/index.js) at Timeout._onTimeout The app catches this via Sentry but does not back off, pause the timer, or alert the user. The timer continues firing at the same rate.

Stage 4 — Compounding pressure. Multiple open sessions meant the timer fired in parallel contexts. Large session transcripts (3–5 MB each) kept session state resident in memory. A concurrent heavy build process added CPU and I/O pressure. The combined resource load — continuous failing system calls + multi-MB in-memory session state + build I/O — exhausted available system resources and caused a hard crash.

What It Looked Like

• No visible warning in the Claude UI. Sessions appeared normal until they stopped responding.
• main.log showed ERR_NETWORK_IO_SUSPENDED during the first sleep, then ERR_NAME_NOT_RESOLVED and ERR_NETWORK_CHANGED on wake, then — on the next app start — a continuous stream of Sentry caught: SystemError ... os.networkInterfaces entries beginning immediately at startup and never stopping.
• Sessions stopped updating at a specific timestamp (the crash moment). All three session JSONL files had identical last-modified times.
• The Windows Application and System event logs showed no independent crash entry — the failure was resource exhaustion inside the app, not a kernel fault.
• After rebooting, the SystemError entries reappeared as soon as the Claude app was relaunched, because the Windows network stack was still in a corrupted state.

How to Reproduce

1. Open 2–3 CoWork sessions across different projects and run non-trivial tasks in each.
2. Allow all tasks to complete but do not close the sessions.
3. Put the machine to sleep twice (or once with a VPN client active — virtual adapters accelerate the driver state corruption).
4. Wake the machine and leave Claude running.
5. Observe main.log (%APPDATA%\Claude\Logs\main.log) — SystemError entries from os.networkInterfaces will begin immediately and repeat every few seconds indefinitely.
6. Start a resource-intensive background process (build, large file operation) while the error storm is running.
7. Result: session crash, app freeze, or full system crash within minutes to hours depending on available RAM and CPU headroom.

Accelerant: Each additional open session multiplies the poll frequency. Three sessions = roughly 3× the error rate, 3× the failed system calls per minute.

Consequences

┌─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────┐
│  Severity   │                                             Effect                                             │
├─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Immediate   │ All open CoWork sessions lose connectivity simultaneously at the same clock second             │
├─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Short-term  │ App UI becomes unresponsive; session state frozen at last-write timestamp                      │
├─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Medium-term │ Continuous SystemError storm degrades system event queue and consumes file handles             │
├─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Worst case  │ Full desktop crash / forced reboot; any unsaved / uncommitted work in open sessions is at risk │
└─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────┘

Work saved to disk (files, git commits) before the crash is intact. Uncommitted in-memory session state (plans, task lists, unsaved files) may be
partially or fully lost.

---
Remedy When Ongoing (System Currently in This State)

Step 1 — Confirm you are in this state.


  Step 1 — Confirm you are in this state.

  Open %APPDATA%\Claude\Logs\main.log and search for:
  SystemError [ERR_SYSTEM_ERROR]: A system error occurred: undefined returned undefined (undefined)
  If you see repeated entries (every few seconds), the network stack is corrupted and the app is actively in this failure mode.

  Step 2 — Close all Claude sessions and quit the app.

  This stops the poll timer immediately and halts the error storm.

  Step 3 — Reset the Windows network stack (run as Administrator, then reboot).

  netsh winsock reset
  netsh int ip reset
  ipconfig /flushdns
  Reboot after running these — the reset is not fully applied until restart.

  Step 4 — After reboot, verify the error is gone.

  Relaunch Claude, wait 60 seconds, then check main.log again. If SystemError entries are absent, the stack is clean. If they persist, open Device
Manager →
   Network Adapters and look for yellow-flagged adapters (common with stale VPN clients or virtual switch drivers). Disabling and re-enabling the
flagged
  adapter, or uninstalling and reinstalling its driver, resolves the remaining cases.

  Step 5 — Operational hygiene going forward.

  - Close CoWork sessions explicitly when work is done rather than leaving them idle.
  - After any sleep/wake cycle, restart Claude before opening new sessions or resuming heavy work.
  - Limit concurrent CoWork sessions to two on a machine without dedicated headroom; each session with a large transcript (>2 MB) holds several
hundred MB
  of in-process state.

  ---
  Root Attribution

  The crash is not caused by the multi-session count alone, nor by sleep/wake alone. It is a conjunction bug: the app's session-bridge polling timer
has no
  error-handling path for os.networkInterfaces() throwing a SystemError, so a corrupted Windows network driver — a transient and recoverable hardware
state
  — becomes a permanent application-level fault that is invisible to the user and self-reinforcing over time. Closing idle sessions earlier would have
  prevented the timer from running long enough for the corrupted driver state to compound into a crash. **Environment**
  - OS: Windows 11 Home 10.0.26200
  - Claude Desktop version: 1.3883.0.0
  - Sessions open at time of crash: 3 (CoWork / local agent mode)
  - Confirmed in main.log: 948 Sentry-caught SystemError entries from os.networkInterfaces() in ~5 hours
- Environment info: win32, windows-terminal, v2.1.118
- Git repo metadata: main, bb05ddb, not synced, has local changes
- Current session transcript

We will use your feedback to debug related issues or to improve Claude Code's functionality (eg. to reduce the risk of bugs occurring in the future).

Press Enter to confirm and submit.

Enter to submit · Esc to cancel If you see repeated entries (every few seconds), the network stack is corrupted and the app is actively in this failure mode.

Step 2 — Close all Claude sessions and quit the app.

This stops the poll timer immediately and halts the error storm.

Step 3 — Reset the Windows network stack (run as Administrator, then reboot).

netsh winsock reset
netsh int ip reset
ipconfig /flushdns
Reboot after running these — the reset is not fully applied until restart.

Step 4 — After reboot, verify the error is gone.

Relaunch Claude, wait 60 seconds, then check main.log again. If SystemError entries are absent, the stack is clean. If they persist, open Device

Manager → Network Adapters and look for yellow-flagged adapters (common with stale VPN clients or virtual switch drivers). Disabling and re-enabling the flagged adapter, or uninstalling and reinstalling its driver, resolves the remaining cases.

Step 5 — Operational hygiene going forward.

- Close CoWork sessions explicitly when work is done rather than leaving them idle.
- After any sleep/wake cycle, restart Claude before opening new sessions or resuming heavy work.
- Limit concurrent CoWork sessions to two on a machine without dedicated headroom; each session with a large transcript (>2 MB) holds several hundred

MB of in-process state.

---
Root Attribution

The crash is not caused by the multi-session count alone, nor by sleep/wake alone. It is a conjunction bug: the app's session-bridge polling timer has

no error-handling path for os.networkInterfaces() throwing a SystemError, so a corrupted Windows network driver — a transient and recoverable hardware state — becomes a permanent application-level fault that is invisible to the user and self-reinforcing over time. Closing idle sessions earlier would have prevented the timer from running long enough for the corrupted driver state to compound into a crash. Environment - OS: Windows 11 Home 10.0.26200 - Claude Desktop version: 1.3883.0.0 - Sessions open at time of crash: 3 (CoWork / local agent mode) - Confirmed in main.log: 948 Sentry-caught SystemError entries from os.networkInterfaces() in ~5 hours

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Submit Feedback / Bug Report

Thank you for your report! Feedback ID: 060645ef-95d2-4a3b-bf44-95faf8eee09c

Press Enter to open your browser and draft a GitHub issue, or any other key to close. Open %APPDATA%\Claude\Logs\main.log and search for: SystemError [ERR_SYSTEM_ERROR]: A system error occurred: undefined returned undefined (undefined) If you see repeated entries (every few seconds), the network stack is corrupted and the app is actively in this failure mode.

Step 2 — Close all Claude sessions and quit the app.

This stops the poll timer immediately and halts the error storm.

Step 3 — Reset the Windows network stack (run as Administrator, then reboot).

netsh winsock reset netsh int ip reset ipconfig /flushdns Reboot after running these — the reset is not fully applied until restart.

Step 4 — After reboot, verify the error is gone.

Relaunch Claude, wait 60 seconds, then check main.log again. If SystemError entries are absent, the stack is clean. If they persist, open Device Manager → Network Adapters and look for yellow-flagged adapters (common with stale VPN clients or virtual switch drivers). Disabling and re-enabling the flagged adapter, or uninstalling and reinstalling its driver, resolves the remaining cases.

Step 5 — Operational hygiene going forward.

• Close CoWork sessions explicitly when work is done rather than leaving them idle.
• After any sleep/wake cycle, restart Claude before opening new sessions or resuming heavy work.
• Limit concurrent CoWork sessions to two on a machine without dedicated headroom; each session with a large transcript (>2 MB) holds several hundred MB of in-process state.

Root Attribution

The crash is not caused by the multi-session count alone, nor by sleep/wake alone. It is a conjunction bug: the app's session-bridge polling timer has no error-handling path for os.networkInterfaces() throwing a SystemError, so a corrupted Windows network driver — a transient and recoverable hardware state — becomes a permanent application-level fault that is invisible to the user and self-reinforcing over time. Closing idle sessions earlier would have prevented the timer from running long enough for the corrupted driver state to compound into a crash. Environment

• OS: Windows 11 Home 10.0.26200
• Claude Desktop version: 1.3883.0.0
• Sessions open at time of crash: 3 (CoWork / local agent mode)
• Confirmed in main.log: 948 Sentry-caught SystemError entries from os.networkInterfaces() in ~5 hours

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Desktop version: 1.3883.0.0
• Sessions open at time of crash: 3 (CoWork / local agent mode)
• Confirmed in main.log: 948 Sentry-caught SystemError entries from os.networkInterfaces() in ~5 hours