[BUG] Retry mechanism fails to recover from connection loss - stale HTTP/2 connection pool not reset

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?

Bug Description

When a Claude Code session loses its API connection (e.g., due to a network interruption), the built-in retry mechanism (11 attempts with exponential backoff) consistently fails to reconnect, even though the network has already
recovered.

The key evidence: during the retry window, other tools using the same proxy work fine, and launching a new Claude Code session also succeeds immediately. Only the original session remains stuck.

This strongly suggests the retry logic reuses stale connection state (HTTP/2 connection pool, TLS session tickets, or DNS cache) instead of establishing a fully fresh connection like a new session would.

What Should Happen?

The retry mechanism should fully reset connection state (close HTTP/2 connection pool, discard TLS session tickets, re-resolve DNS) before each retry attempt, similar to what happens when starting a fresh session.

Error Messages/Logs

Two occurrences captured in a single session:

  First occurrence

  12:55:46 [ERROR] Error streaming, falling back to non-streaming mode: socket closed unexpectedly
  12:56:56 [ERROR] Error streaming, falling back to non-streaming mode: socket closed unexpectedly
  12:57:27 [ERROR] API error (attempt 1/11): undefined Connection error.
  ...
  13:05:48 [ERROR] API error (attempt 11/11): undefined Connection error.
  13:05:48 [ERROR] Connection error details: code=ECONNRESET

  Second occurrence (~1 hour later, same session)

  14:04:12 [ERROR] Error streaming, falling back to non-streaming mode: socket closed unexpectedly
  14:07:39 [ERROR] API error (attempt 6/11): undefined Connection error.
  ...
  14:12:57 [ERROR] API error (attempt 11/11): undefined Connection error.
  14:12:57 [ERROR] Connection error details: code=ECONNRESET

  In both cases, other network activity through the same proxy worked normally during the retry window.

Steps to Reproduce

1. Start a Claude Code session through a proxy (SOCKS5 or HTTP)
2. Work normally for a while (streaming responses)
3. Trigger a brief network interruption (e.g., proxy restart, VPN reconnect, or transient network blip)
4. Observe Claude Code enter retry mode

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

• Claude Code version: 2.1.29 / 2.1.31 - OS: Ubuntu 22.04 (x86_64) - Kernel: 6.8.0-90-generic - Node/Bun runtime: bundled with Claude Code - Proxy: SOCKS5/HTTP (tested with both shadowsocks-libev + privoxy, and sing-box) - Connection: behind NAT, proxy to reach api.anthropic.com

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

## Hypothesis

The retry logic likely reuses the existing fetch() / HTTP client instance which holds:

• An HTTP/2 connection pool with dead connections
• TLS session cache pointing to the old (possibly now-unreachable) connection path
• Cached DNS results

A new Claude Code session creates all of these fresh, which is why it works immediately. The fix would be to destroy and recreate the HTTP client (or at minimum flush its connection pool and TLS session cache) before each retry attempt.