Bedrock streaming stalls hang forever with no error in UI

Description

When using Claude Code with Amazon Bedrock (CLAUDE_CODE_USE_BEDROCK=1), if the API streaming response stalls mid-generation, Claude Code hangs indefinitely with a spinner and never surfaces an error to the user. There is no client-side idle timeout to detect when tokens stop arriving on the stream.

Reproduction

1. Configure Claude Code to use Bedrock (CLAUDE_CODE_USE_BEDROCK=1)
2. Use a model that produces long outputs (e.g., Opus with maxOutputTokens: 64000)
3. Issue a prompt that requires a large generation (e.g., writing a comprehensive report after gathering data from multiple agent findings)
4. Observe that the stream begins (partial text is logged), then stalls

Observed Behavior

• The spinner continues indefinitely with no feedback
• No error message is shown in the UI
• The session JSONL log shows the last assistant message with stop_reason: None — the response never completed
• Zero error type entries are logged
• The session log file stops being written to (in my case, 7+ minutes with no new data)
• The user has no indication anything is wrong other than the spinner not stopping

Expected Behavior

• Claude Code should detect when no new tokens have arrived on an active stream for some threshold (e.g., 60-120 seconds)
• When a stall is detected, it should:
• Surface an error message in the UI (e.g., "API response timed out — no data received for X seconds")
• Log an error entry in the session JSONL
• Ideally offer to retry the request

Evidence from Session Logs

Investigating the JSONL session log showed:

• Last logged assistant entry had partial content: "Good, the directory exists. Now let me write the comprehensive level analysis report."
• stop_reason was None (response never completed)
• error entries in session: 0
• Time since last log write: 7+ minutes and counting
• The session appeared completely healthy from the log perspective — just incomplete

Environment

• Claude Code version: 2.1.62
• Model: us.anthropic.claude-opus-4-6-v1 via Bedrock
• Platform: macOS (Darwin 24.6.0)
• maxOutputTokens: 64000 configured in settings

Workaround

The only workaround is to manually interrupt (Escape/Ctrl+C) the hung session and re-prompt. Since there's no error feedback, users have to guess when a session is actually stuck vs. just generating slowly.

Suggestion

A configurable client-side stream idle timeout (e.g., api.streamIdleTimeoutMs) with a sensible default would solve this. Something like:

{
  "api": {
    "streamIdleTimeoutMs": 120000
  }
}