[BUG]

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?

Environment:

• Claude Code CLI: 2.1.126
• OS: macOS (Darwin 25.1.0)
• Plan: Max 20x
• Shell: zsh

What Should Happen?

Description:
Claude Code intermittently enters a retry loop (Retrying in 0s · attempt 1/10 … attempt 10/10) and then fatally
exits mid-response. Happens on streaming SSE responses during normal turns — not tied to any specific tool call or
prompt size.

Reproduces on:

• Long-running sessions
• Fresh, tiny sessions (just started, single short prompt) — so it's not a context-size issue

Ruled out from my side:

• Anthropic API status: operational
• Local network: 0% packet loss, 0 timeouts over 5min ping
• Rate limit: on Max 20x (top tier), happens well under any cap
• CLI version: latest (2.1.126)
• IPv4 vs IPv6: 10/10 single-shot curls clean on both
• DNS: resolves fine
• VPN / proxy: none running

What I couldn't probe: how the CLI handles streaming SSE specifically — single-shot curl probes don't exercise
the same path that emits Retrying in 0s · attempt N/10. Suspect this is in the streaming/retry handling in the
client, not server- or network-side.

Workaround I'm using: when retries start, /exit immediately — waiting for it to go fatal loses the session.

What would help debug: any way to enable verbose logging of the SSE stream / retry decisions (env var, --debug
flag) so I can capture the failure mode and attach a log next time it happens.

Error Messages/Logs

Steps to Reproduce

Description:
Claude Code intermittently enters a retry loop (Retrying in 0s · attempt 1/10 … attempt 10/10) and then fatally
exits mid-response. Happens on streaming SSE responses during normal turns — not tied to any specific tool call or
prompt size.

Reproduces on:

• Long-running sessions
• Fresh, tiny sessions (just started, single short prompt) — so it's not a context-size issue

Ruled out from my side:

• Anthropic API status: operational
• Local network: 0% packet loss, 0 timeouts over 5min ping
• Rate limit: on Max 20x (top tier), happens well under any cap
• CLI version: latest (2.1.126)
• IPv4 vs IPv6: 10/10 single-shot curls clean on both
• DNS: resolves fine
• VPN / proxy: none running

What I couldn't probe: how the CLI handles streaming SSE specifically — single-shot curl probes don't exercise
the same path that emits Retrying in 0s · attempt N/10. Suspect this is in the streaming/retry handling in the
client, not server- or network-side.

Workaround I'm using: when retries start, /exit immediately — waiting for it to go fatal loses the session.

What would help debug: any way to enable verbose logging of the SSE stream / retry decisions (env var, --debug
flag) so I can capture the failure mode and attach a log next time it happens.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Description:
Claude Code intermittently enters a retry loop (Retrying in 0s · attempt 1/10 … attempt 10/10) and then fatally
exits mid-response. Happens on streaming SSE responses during normal turns — not tied to any specific tool call or
prompt size.

Reproduces on:

• Long-running sessions
• Fresh, tiny sessions (just started, single short prompt) — so it's not a context-size issue

Ruled out from my side:

• Anthropic API status: operational
• Local network: 0% packet loss, 0 timeouts over 5min ping
• Rate limit: on Max 20x (top tier), happens well under any cap
• CLI version: latest (2.1.126)
• IPv4 vs IPv6: 10/10 single-shot curls clean on both
• DNS: resolves fine
• VPN / proxy: none running

What I couldn't probe: how the CLI handles streaming SSE specifically — single-shot curl probes don't exercise
the same path that emits Retrying in 0s · attempt N/10. Suspect this is in the streaming/retry handling in the
client, not server- or network-side.

Workaround I'm using: when retries start, /exit immediately — waiting for it to go fatal loses the session.

What would help debug: any way to enable verbose logging of the SSE stream / retry decisions (env var, --debug
flag) so I can capture the failure mode and attach a log next time it happens.