Bedrock streaming stalls hang forever with no error in UI
Status Fixed / completed
Reported on v2.1.62
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 5 comments · opened Feb 27, 2026 · closed Feb 27, 2026
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
- Configure Claude Code to use Bedrock (
CLAUDE_CODE_USE_BEDROCK=1) - Use a model that produces long outputs (e.g., Opus with
maxOutputTokens: 64000) - Issue a prompt that requires a large generation (e.g., writing a comprehensive report after gathering data from multiple agent findings)
- 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
errortype 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_reasonwasNone(response never completed)errorentries 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-v1via Bedrock - Platform: macOS (Darwin 24.6.0)
maxOutputTokens: 64000configured 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
}
}
5 Comments
Additional Data: 12-hour analysis of Bedrock streaming stalls
I analyzed my Claude Code session logs from the past ~12 hours (evening through next afternoon) and the numbers paint a stark picture.
Aggregate Stats
| Metric | Value |
|--------|-------|
| Sessions active in period | 24 |
| Incomplete responses (
stop_reason: nullwith partial content) | 395 || Error entries logged for those failures | 0 |
| Stream stalls >= 3 minutes | 18 |
| Stream stalls >= 5 minutes | 14 |
| Max single stall duration | 599 seconds (~10 min) |
Zero errors were surfaced for 395 incomplete API responses. The user receives no indication anything went wrong.
Stall Patterns Observed
There are two distinct stall scenarios, both silent:
1. Mid-response stream death — The assistant begins streaming (partial text or thinking token received), then the stream stalls.
stop_reasonisnull. Examples from logs:thinkingtoken → 552s stall → eventually resumed via system heartbeattool_use:Read→ 284s stall → system heartbeat broke it2. Post-tool-result API hang — Tool results are delivered to the API, but the next response never begins streaming. Examples:
tool_resultdelivered → 592s wait → assistant finally respondedtool_resultdelivered → 577s wait → system heartbeattool_resultdelivered → 554s wait → system heartbeatThe ~5 minute (300s) heartbeat pattern
Many sessions show a characteristic repeating pattern of
system → systementries at exactly 300-second intervals, sometimes 10-15 in a row. This appears to be an internal keepalive/heartbeat. In the worst case, a session showed 25 consecutive 300s system heartbeats spanning over 2 hours while appearing to be stuck.Impact on workflows
Environment
CLAUDE_CODE_USE_BEDROCK=1)us.anthropic.claude-opus-4-6-v1)maxOutputTokens: 64000Requested improvements
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Looks like mine is a duplicate of several. I hope the context I provided here will help in troubleshooting this issue. I am not sure which duplicate to attach my findings to.
Closing as duplicate of #25979. Posted my detailed Bedrock analysis there.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.