[Bug] claude CLI silently exits on transient network errors during tool-use turns (no retry, no backoff)

Summary

When the claude CLI makes an API call to api.anthropic.com during a tool-use turn and the network becomes temporarily unreachable (DNS failure, HTTP timeout, connection reset), the session terminates silently and cleanly. There is no retry, no exponential backoff, no error message displayed to the user. The session exits as if the user had typed /exit. This breaks long-running automation workflows — particularly orchestrator-style sessions — where a brief network blip should be a recoverable transient event, not a session-ending failure.

Steps to Reproduce

1. Start a long-running claude session in tmux or byobu (orchestrator or autonomous workflow mode).
2. While the session is mid-turn executing a tool call (file edit, MCP call, subprocess launch), trigger a transient network interruption:

• Temporarily block outbound traffic to api.anthropic.com (e.g. via firewall rule, DNS failure, or network interface bounce)
• Or wait for a natural network blip on a residential/VPN connection

1. Observe: the session terminates immediately and cleanly. No retry attempt. No error printed to the terminal. No Ctrl-C signal detected.

Expected behavior: The CLI retries the API call with exponential backoff (e.g. 3 attempts: 1s, 2s, 4s) before giving up. If all retries are exhausted, it prints a clear error message and exits gracefully. It does not exit silently mid-turn.

Observed behavior: Immediate silent exit. The byobu/tmux pane shows the shell prompt as if the process completed normally. No indication that a network error occurred.

Evidence — Two Confirmed Incidents

Both incidents occurred within 24 hours on the same host. Neither had context exhaustion, OOM, or user-initiated exit as a cause.

Incident A — session cc-kHJqsbOO

• Token count at termination: 482k (model cap: 1M for claude-opus-4-7)
• Session was mid-tool-use: editing a YAML file via the Edit built-in tool
• Network-layer evidence: rygel logged network errors on the same host 47 seconds after the claude transcript's last recorded event — consistent with a pending API call timing out and triggering session exit
• No SIGSEGV, no abort, no OOM entry in dmesg, no kill in the user's shell history, no /exit in the conversation transcript
• Recovery: claude --resume restored full conversation context; no work lost

Incident B — session cc-LQEi5YOS

• Token count at termination: 335k (model cap: 1M)
• Session lifetime: approximately 5–8 minutes after bootstrap (clearly not context exhaustion)
• Session was mid-turn processing: two inbound signal events + two large system-reminder pastes arriving in the same turn
• Same clean-exit signature: no crash signal, no OOM, no /exit
• Recovery: claude --resume restored full context; no work lost

Both incidents match a single failure mode: claude exits cleanly when the underlying API call fails at the network layer, rather than retrying.

Suggested Fix

Add retry-with-backoff logic in the API client layer for transient network errors:

• HTTP 5xx responses from api.anthropic.com
• Connection reset / EPIPE errors
• DNS resolution failure (NXDOMAIN / EAI_AGAIN)
• HTTP timeout (request sent, no response within N seconds)

Suggested retry policy: 3 attempts with exponential backoff (1s → 2s → 4s delays). After all retries are exhausted, print a human-readable error message and exit with a non-zero exit code. The current silent-exit behavior is indistinguishable from a normal exit and makes debugging extremely difficult.

Optionally, consider a --retry-on-network-error flag (defaulting to enabled) to allow users to opt out if desired.

Workaround

A local watchdog script can detect when the claude process has exited unexpectedly (by monitoring the PID and checking for stagnant transcript activity), then automatically invoke claude --resume. This works around the problem at the OS layer but is fragile — it requires the session to have been started inside a persistent terminal multiplexer, relies on timing heuristics, and adds complexity for users who want reliable long-running sessions.

The correct fix is in the CLI itself.

Environment

• claude --version: 2.1.128 (Claude Code)
• Platform: Linux 6.1.0 x86_64 (Debian)
• Model: claude-opus-4-7
• Session mode: interactive CLI in byobu (tmux-based), persistent orchestrator workflow