[BUG] Stream idle timeout / partial response during long tool-use turns on Claude Code Web (Opus 4.7, 1M and non-1M)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/48974
2. https://github.com/anthropics/claude-code/issues/48901
3. https://github.com/anthropics/claude-code/issues/47555

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I am getting the same !!!

Same here

Me too. Multiple times today

Why have all of the possible duplicated been closed as duplicates?

Where's the master bug record?

Same failure mode:

• Multi-turn planning session on a non-trivial private repo with a

custom CLAUDE.md, context at roughly 33% of the window.

• Asked the assistant to rewrite a long markdown planning document

from scratch as a handoff for a new session.

• Model performed 1–2 exploratory tool calls (file read, scan),

then began the Write call.

• Stream terminated with `API Error: Stream idle timeout - partial

response received` before the write completed in the UI.

• Retried 4 times across 2 separate sessions on the same repository

over 2 consecutive days. All failed at roughly the same point.
Reducing the scope of the write did not help.

• Sessions remained alive, but the same turn could not be

completed — consistent with this being a keep-alive / heartbeat
gap between tool-result-accepted and the next assistant token,
not a model or tool-execution issue.

Workarounds suggested by support (manual chunking of the write,
raising CLAUDE_STREAM_IDLE_TIMEOUT_MS) do not apply to the Cloud
/ browser surface. Confirmation that a fix is in progress for this
specific surface would be appreciated.

I encounter this frequently, and it makes cc on the web almost unusable for me, as my workflow frequently involves large yaml file edits.

In case it's not obvious from the OP, attempting to coax it along by saying "try again" or similar is a great way to burn tokens to no avail. When this does happen, I say:

"Commit and push what you have so far. Do not create more yaml. No more writes. I don’t care if it doesn’t validate. Commit and push NOW"

Then create a PR so I have the option of taking over in a terminal session. After that I might try asking it it break down its edits into smaller units, which is often successful.

Having the same issues - it's driving me crazy. Sadly no one is actively trying to fix it and we have to find complex workarounds

Chiming in, this happens to me pretty much every single time I use Claude.ai/code. Makes the product pretty much unusable.

I have noticed that is a 4.7 opus thing though, as sonnet 4.6 and haiku 4.5 have no such issues. Truly, opus 4.7 is the regression king.

+1 — Same issue on Windows native Claude Code (npm-global, v2.1.121, Node v22 LTS, web login auth).

Reproducible on a large monorepo:

• ~240 markdown files in docs/, 22 Docker microservices
• Initially had 53k char CLAUDE.md → slimmed to 9.7k chars + split into 10 docs/ files
• Slimming helped with simple queries (now work in seconds ✅)
• BUT complex multi-tool tasks still fail with "API Error: Stream idle timeout - partial response received"

Specific pattern observed:

• Simple read/search tasks: work fine
• Complex tasks involving multiple file searches + analysis + extended thinking: fail consistently
• Failure point: between tool result delivery and next assistant token (matches Pattern 2 from #25979)
• Extended thinking ("xhigh effort") seems to amplify the issue
• Task example that fails: "Failed to load preflight report" debugging across UI + agent code

Workarounds tested:

• Slim CLAUDE.md ✅ helps simple tasks, ❌ doesn't fix complex
• Reinstall Claude Code with Node v22 LTS ✅ helps initial connection, ❌ same timeout on long tasks
• Antivirus disabled (Defender) ❌ no change
• Network verified clean (Test-NetConnection OK, no SSL inspection)
• Splitting tasks into smaller steps ✅ works as workaround

Question for maintainers:
Is CLAUDE_STREAM_IDLE_TIMEOUT_MS effective in practice for this scenario, or does the issue lie deeper in keep-alive between tool-result and next-token?

Happy to provide more session details if helpful.

Adding data to this issue — we're seeing the same pattern via the Anthropic MCP Connector (mcp-client-2025-11-20 beta, not Claude Code, but the same streaming-stall signature).

Environment

• Model: claude-opus-4-7 via Messages API with mcp_servers parameter
• Beta header: mcp-client-2025-11-20
• max_tokens: 2000, no extended thinking, stream=True
• SDK: anthropic==0.96.0
• Remote MCP server: HTTPS-exposed, OAuth-authenticated, backed by Snowflake
• Network confirmed healthy (TCP/SSE pings flow throughout the stall)

Symptom

On approximately 4 out of 5 events in a controlled test harness, the streaming response stalls for ~300 seconds between content_block_stop type=mcp_tool_use and content_block_start type=mcp_tool_result. The pattern is reproducible and consistently ~300s ± 15s — strongly suggesting a fixed-duration timeout-and-recover rather than genuine processing time.

During the stall:

• The TCP/SSE connection stays alive — ping events arrive at metronomic 30.000s ± 0.030s intervals for the entire gap (typically 10 pings)
• thinking_delta_count = 0 (extended thinking is not enabled)
• message_start_count = 1 (no silent reconnect)
• Single tool calls on the same session, before and after the stalled batch, complete in 4.6–9.0 seconds — so the session itself is not degraded

What's different about the stalled calls

The stall reproduces specifically on parallel tool-call batches. When the model emits two or more mcp_tool_use blocks back-to-back (idx=4 and idx=5 in our trace, emitted 0.776s apart), the gateway holds all results and then flushes them in a single batch — both mcp_tool_result blocks (idx=6 and idx=7) arrive within 2ms of each other after the 300s stall.

Single-tool calls in the same stream complete normally:

• idx=1 (single get_database_metadata): 9.0s round-trip ✓
• idx=4 + idx=5 (parallel batch of 2 sql_exec): 301.9s round-trip ✗
• idx=9 (single sql_exec after the gap): 4.6s ✓
• idx=12 (single sql_exec): 4.8s ✓

This matches the regression behavior reported in #14353, and the "proxy holds tool_results" pattern in #38437.

Three-source correlation isolates the stall upstream of the MCP server

We instrumented and cross-correlated three independent log sources for one stalled event (gap: 2026-05-20T17:26:41.464Z → 17:31:43.370Z, 301.9 seconds):

| Source | Activity during the 301.9s gap |
|--------|--------------------------------|
| Harness stream-event log | 10 pings, no content blocks, no errors |
| Snowflake ACCOUNT_USAGE.QUERY_HISTORY | 0.949s of actual query execution; idle for the remaining 298s |
| MCP server (assistant_tool_invocations) | Tool calls logged with normal duration_ms values [confirm fast durations before posting] |

The MCP server returned its responses promptly. Snowflake idled for 298 of the 302 seconds. The Anthropic gateway then held the batched results for the remaining time before streaming them back. The latency is unambiguously upstream of the MCP server.

Related issues

This appears to be the same root behavior described in:

• #18028 — streaming stalls of 59–138s, network healthy, no errors
• #44 (claude-agent-sdk-typescript) — 3+ minute pauses, no events, no pings during gap (we do see pings, but the stall mechanism looks similar)
• #38437 — MCP proxy silently holding tool_results that the upstream MCP server has already returned
• #49619 — author's diagnosis: "the issue is in keep-alive / heartbeat between tool-result-accepted and next-assistant-token, not in the tool execution itself" — matches our finding
• #25979 — no client-side read timeout on streaming, so stalls can run to inactivity timeout
• #14353 — parallel MCP tool calls regressed to sequential in v2.0.71

Reproduction

Anyone can repro with the MCP Connector beta:

1. Configure mcp_servers to point to a remote MCP server that exposes 2+ fast tools
2. Send a prompt that induces the model to issue 2+ parallel tool calls (e.g. "Look up X and Y at the same time")
3. Stream the response and log content_block_start / content_block_stop events with timestamps
4. Observe: in a fraction of runs (in our experiment ~80% of events on condition_b_snowflake and condition_c_semantic), the parallel batch stalls for ~300s before results arrive together

Happy to file this as a fresh issue if the maintainers prefer to keep #18028 scoped to the Claude Code CLI case rather than the MCP Connector API case — but they look like the same underlying mechanism.

Workaround that worked for me:

Switching from Opus to Sonnet resolved the frequent hang/freeze issues I was experiencing.

Environment:

• Platform: Claude Code CLI (desktop app on macOS)
• Model before: claude-opus-4-7 (Max plan — auto-upgraded to claude-opus-4-7[1m])
• Model after: claude-sonnet-4-6
• Result: Hangs stopped completely after switching to Sonnet

Note:
On Max/Team plans, selecting Opus automatically upgrades to the 1M context version, which cannot be avoided through the /model picker alone. Setting CLAUDE_CODE_DISABLE_1M_CONTEXT=1 in ~/.claude/settings.json disables the auto-upgrade if you want to stay on Opus.

Hope this helps others experiencing similar issues.