[BUG] Long-running sessions on older builds stuck on ECONNREFUSED for every request until /exit + --resume; newer-build sessions on the same machine unaffected (error omits host:port)

What's wrong

One long-running interactive session got stuck returning

API Error: Connection refused — a firewall or proxy may be blocking it (ECONNREFUSED)

for every request for ~25 minutes, while other Claude Code sessions on the same machine, same user, same network, kept working normally the whole time. Typing continue and sending new prompts did not help — each attempt failed the same way. /exit followed by claude --resume <session-id> in the same terminal fixed it immediately; the resumed session's first request succeeded.

So the failure was local to that one process, not to the network.

Timeline (UTC, 2026-10-13)

| time | event |
|---|---|
| 04:40:45 | last successful turn (a Bash tool call that ran az + curl, completed normally at 04:41:11) |
| 04:44:00 | first ECONNREFUSED |
| 04:48:42, 04:56:02, 05:00:19, 05:05:33, 05:08:24 | same error on each new prompt |
| ~05:17 | /exit → claude --resume <id> in the same pane |
| 05:18:01 | first request after resume succeeds; session continues normally |

The process had been running ~3.7 days (started 2026-10-09, v2.1.295; v2.1.296 had been auto-installed on 2026-10-10 and the session kept working for 3 more days after that, so the update by itself does not seem to be the trigger). The status line showed ✔ Update installed · Restart… while it was failing.

Which sessions were affected

All sessions on this machine that made requests between 04:30 and 05:20 UTC:

| session | version | process started (UTC) | assistant turns OK | API errors |
|---|---|---|---|---|
| A (the one above) | 2.1.295 | 2026-10-09 | 0 | 6 × ECONNREFUSED (04:44–05:08) |
| B | 2.1.290 | 2026-10-05 | 0 | 1 × ECONNREFUSED (04:59:42) |
| C | 2.1.296 | 2026-10-12 14:55 | 69 | 0 |
| D | 2.1.296 | 2026-10-12 14:21 | 189 | 0 |
| E | 2.1.296 | 2026-10-13 04:33 | 207 | 0 |
| F | 2.1.296 | 2026-10-13 04:54 | 87 | 0 |

So in that window, the only failures came from the two processes running older builds that had been up for days; every request from 2.1.296 processes succeeded (C was also up for >14 h, so it isn't just process age).

Afterwards (≈05:40 UTC) I ran each installed binary fresh — ~/.local/share/claude/versions/{2.1.290,2.1.295,2.1.296} -p "Reply with exactly: ok" — and all three returned ok. So an old build is not broken per se; it was the long-running old-build processes that failed, and they did not recover on their own.

What I checked while it was failing

• curl https://api.anthropic.com/v1/models from the same machine → 401 in ~0.5 s (reachable).
• Other sessions (started before and after this one) → working.
• lsof on the stuck process showed ESTABLISHED TCP connections to the address api.anthropic.com currently resolves to.
• No HTTP(S)_PROXY / ANTHROPIC_BASE_URL in the environment or in any settings.json.
• Network: home router running a transparent proxy (fake-IP DNS, 198.18.0.0/15), no local proxy port on the Mac.
• ~/.claude/settings.json had been rewritten 28 s before the first failure (unrelated keys, nothing network-related) — mentioning it only because of the timing.

I could not determine which host:port refused the connection, because the error message does not say.

What should happen

1. The error should include the destination (host, resolved IP, port, address family) — with that, this would have been a one-line diagnosis instead of guesswork.
2. If the same process keeps getting connection-refused while the host is otherwise reachable, the client should drop and rebuild its connection pool / DNS cache (or expose a /reconnect), so the user doesn't have to /exit and --resume to recover.

Environment

• Claude Code 2.1.295 (native install, auto-update on), interactive CLI inside a terminal multiplexer
• macOS (Apple Silicon)
• Anthropic API (Claude subscription login)

Workaround

/exit, then claude --resume <session-id> (the session id is in ~/.claude/sessions/<pid>.json). I wrote a small script that finds sessions whose transcript ends in repeated API connection errors and re-launches them with --resume in their tmux/herdr pane: https://github.com/SunflowersLwtech/sunkit/tree/main/tools/session-rescue (claude_rescue.py scan / revive)