[BUG] Claude Code + Cowork fail with ECONNRESET on every network and client — chat works fine

+1, same issue on a second, independent account. Claude Code CLI and Cowork both fail with the same retry/connection-failure pattern; Claude.ai chat works fine on the same account.

What I've ruled out (matches the OP's list closely):
• Tested on 3 separate networks: home wifi, two different 5G routers, phone hotspot — same failure on all
• Ran /doctor — same failure
• Full logout, deleted local credentials, fresh login on both Claude Code and Cowork — same failure persists
• Chat works normally on the same account/machine the whole time

Ongoing about 1 week. Also opened a support.claude.com case, explicitly asked for human escalation — got only generic Fin AI Agent auto-replies, and one follow-up generated a second, separate conversation ID instead of merging into the existing case. No human response yet.

Given two independent accounts hitting the identical signature, this looks server-side and account/entitlement-related rather than a local environment issue. Flagging for visibility since support hasn't resolved it either.

Same issue here, started ~2 days ago. Windows, Claude Code 2.1.227 (latest), Max plan. Nearly every request fails with Connection dropped (ECONNRESET) · Retrying, including the first message in a fresh empty workspace. Reproduces on both the Desktop app and the CLI.

Confirmed it's not my network:

5 consecutive curl -X POST https://api.anthropic.com/v1/messages → all 401, zero resets
netsh winhttp show proxy = Direct access (no proxy)
No VPN (all disabled), Windows Defender Network Protection disabled
claude.ai in the browser works perfectly at the same moment, same machine/network

Already tried (none fixed it): updated 2.1.222→2.1.227, clean reinstall, sign out/in, ANTHROPIC_API_TIMEOUT_MS + UV_THREADPOOL_SIZE env vars, empty workspace.

This matches the documented HTTP/2 connection-pool ECONNRESET pattern (#67091, #51164). The requested upstream fix is more aggressive TCP keepalive / force-closing the pool on ECONNRESET instead of reusing a dead socket.

bumping it again , i cant work with claude for 2 days, it feels that i am wasting my money on max plan when i cant even work!

Same here still - emailed Anthropic, got a message from Fred and told him that I want to get in touch with a human. Have been waiting for 2 days now.

Another data point supporting the client-side / stale-connection-pool diagnosis, with two observations I haven't seen elsewhere in this thread: a transcript-size correlation (matching #51164) and small requests failing inside the same process while fresh connections from other processes succeed at the same moment.

Environment

• macOS (Darwin 25.3.0), Apple Silicon, native install
• Reproduced across three CLI versions (pre-2.1.224 → 2.1.227 → 2.1.228)
• Claude Team/org account; coworkers on the same org, different machines, are unaffected
• No VPN (default route via en0), no proxy env, no content-filter/network system extensions, no NODE/TLS env overrides

Symptom timeline (extracted from session transcripts, isApiErrorMessage: true entries)

• Background since early July: ~1/day "Connection closed mid-response", occasional ENOTFOUND
• 2026-08-05, 15:00–20:59 + spillover past midnight: 20× Unable to connect to API (ECONNRESET) across many concurrent sessions
• 2026-08-11: 9× ECONNRESET / Connection dropped (ECONNRESET), 6 of them within one hour

Network is exonerated — the failure follows the machine

• Reproduces identically on residential cable Wi-Fi and iPhone hotspot (different ISP, different IP stack)
• During and between bursts, curl probes to https://api.anthropic.com/v1/models succeed on both IPv4 and IPv6, connect in 20–50 ms, clean TLS
• Consistent with the pktmon capture in #85692 showing the RST is generated by the local machine's client, not received from the network

Errors track accumulated session size (matches #51164)

Error count per session vs. its transcript (.jsonl) size:

| Transcript size | API errors |
|---|---|
| 25 MB | 10 |
| 10 MB | 1 |
| 9 MB | 1 |
| 6 MB | 1 |
| 5 MB | 2 |
| 4 MB (×3 sessions) | 6 |
| < 1 MB (vast majority of ~300 sessions/month) | rare one-offs |

I'm a heavy user (multiple concurrent sessions, subagent fan-outs, 11 sessions > 6 MB in the last 30 days). My coworkers never see this. That's consistent with the failure tracking re-uploaded request size / long-lived streams, not account or network.

Same-process observation (stale-pool smoking gun?)

During the 08-11 burst, the CLI's own auxiliary requests (the auto-mode permission classifier — small, non-streaming) failed with "temporarily unavailable" at the same moments the main streaming requests were resetting — while a plain curl from a separate process on the same machine succeeded instantly. Everything sharing the CLI process's connection pool failed together; everything on a fresh connection worked. That's exactly the "pool keeps reusing a dead socket instead of force-closing on ECONNRESET" behavior suggested here and in #67091/#62045.

Extraction method (for anyone who wants to contribute the same data)

find ~/.claude/projects -name '*.jsonl' -print0 | xargs -0 cat \
  | jq -r 'select(.isApiErrorMessage==true) | .timestamp[0:13] + " | " + (.message.content[0].text // "?" | .[0:70])' \
  | sort | uniq -c

(Exclude the session you run this from — its own tool output echoes the error strings.)

Happy to provide debug logs or run instrumented builds against the 25 MB session if that helps.