[BUG] Turns hang ~6 minutes then "Connection dropped (ECONNRESET)", sudden onset 2026-09-28, across all sessions on one Mac

Two separate fingerprints in this write-up — worth keeping distinct when bisecting.

1) The ~6 minute hang → ECONNRESET

The 5m54s–6m09s cluster on 22/26 failed turns is the useful signal. That lands near the ~346s keepalive / idle-socket patterns people have been chasing in #96070 / #95616 / #94422 / #67091. A few things that usually split "API / path" from "client idle timeout" without needing a big new sample:

• Capture one failing turn with NODE_DEBUG=http,net (or equivalent) and note whether the TCP reset arrives from the peer vs a local close after silence.
• Compare a fresh session vs a session that sat idle ≥5–6 minutes before the first prompt (you already note idle-first is common).
• Keep one session on 2.1.282 and one on 2.1.284 with the same model/account for a short side-by-side; if only 284 dies at ~6m, that narrows to the client build rather than Starlink/Tailscale.

Status-page clean + ~0.2s API RTT at the same moment already argues against a blunt outage.

2) --continue drops the channel plugin MCP server

This looks independent of the reset: banner shows, but no bun child for plugin:telegram@claude-plugins-official until you drop --continue. That smells like continue-path not re-hydrating channel / MCP side-servers the same way a cold start does. If you can grab one log line where the continue path decides "channels already present / skip spawn" vs never registering the plugin server, that would pin it for the team.

Happy to compare notes if anyone else on Max + channels + tmux sees the same 6m cliff after 2.1.283/284.

Same symptom here, on the Claude Desktop app (bundled Claude Code), macOS 26 (Darwin 25.6.0).

ECONNRESET count per day, from ~/Library/Logs/Claude/main*.log:

| Date | Errors | Bundled CC version |
|---|---|---|
| 2026-09-23 | 4 | 2.1.281 |
| 2026-09-24 | 4 | 2.1.281 |
| 2026-09-25 | 7 | 2.1.281 |
| 2026-09-26 | 4 | 2.1.281 |
| 2026-09-28 | 7 | 2.1.281 |
| 2026-09-29 | 19+ | 2.1.284 (auto-installed 2026-09-29 02:18 local) |

The errors roughly tripled once 2.1.284 landed.

Log pattern:

[warn] [CCD CycleHealth] <session> api_error (success): API Error: Connection dropped (ECONNRESET)
[info] [CCD CycleHealth] unhealthy cycle for <session> (182s … 2414s, hadFirstResponse=true, reason=api_error)

Every failure has hadFirstResponse=true, so the reset happens mid-stream. Cycle durations vary widely (180–2400 s) rather than clustering around a fixed NAT timeout.

Environment / already ruled out:

• Wired Ethernet to a consumer router, on an Indonesian ISP (XL Axiata); also happens on mobile tethering
• No VPN or proxy; IPv6 disabled; DNS set to 1.1.1.1 / 8.8.8.8
• 0% packet loss; curl https://api.anthropic.com is fine
• Already using CLAUDE_CODE_MAX_RETRIES=10 and API_TIMEOUT_MS=900000

Workaround: I downgraded the standalone CLI (claude install 2.1.282 + DISABLE_AUTOUPDATER=1). It works so far on a short sample. There is no way to pin the version bundled in Desktop, so Desktop is still affected. A way to pin or roll back Desktop's bundled Claude Code would really help until this is fixed.

Same signature here, same onset: 2026-09-28 ~22:05 EDT, macOS 26.3 (25D125), Claude Code 2.1.281, Opus 1M on Max, several sessions on one Mac. Big sessions died with API Error: Connection dropped (ECONNRESET) ~360s after each request (server_error, 0 tokens in the transcript). Small, fresh sessions kept working. We saw no relevant incident on status.claude.com at the time.

In our case the evidence points to the Mac's own upload path, not Claude Code, and restarting the Mac fixed it. Here's the data in case it helps others triage:

• Sized upload test (single TCP connection, curl --data-binary POST to speed.cloudflare.com/__up): 400KB passed, but ≥800KB stalled and was reset at ~15s (curl exit 56). The same happened against two other unrelated echo servers, on HTTP/1.1 and HTTP/2, over IPv4 and IPv6. Apple networkQuality still reported 130–230 Mbps up, so multi-flow tests looked healthy.
• Pacing the upload (curl --limit-rate 500K–1500K) made 3MB pass; at 2MB/s or more it failed.
• A router reboot, TSO off, ECN off and SACK off did not help. net.inet.tcp.rack=0 recovered about half (5/10).
• Packet capture of a failing 3MB upload (taken on the Mac's Wi-Fi interface): a few segments were lost on the path, and the server's SACK blocks showed the holes. Within ~20ms the server sent 23 duplicate ACKs. We then saw zero packets leave the Mac for 15s: no fast retransmit, no RTO retransmit. The server sent RST at +15.0s. So we saw loss on the path, and no recovery attempt from the Mac.
• The Mac had been up 52 days. After a plain restart (all sysctls back at defaults), 3MB uploads passed 10/10 in 0.2–0.5s. All 8 sessions we resumed came back normally, including three that had died and one at ~826k context.

Quick check if you hit this: run the upload below. If 3MB takes ~15s and exits 56, and the Mac has been up for weeks, a restart may be worth trying early, before deeper Claude Code debugging.

f=$(mktemp); head -c 3000000 /dev/urandom > "$f"
curl -s -o /dev/null --max-time 40 -w "http=%{http_code} t=%{time_total}s\n" \
  -X POST --data-binary @"$f" https://speed.cloudflare.com/__up; rm -f "$f"

We haven't proven which component went stale (the TCP stack or the Wi-Fi driver). The original reporter is on Starlink, so the path-loss half may differ. If the Claude Code side could surface "upload stalled" instead of retrying silently for ~6 minutes, it would have saved us a few hours.