[Bug] SSE stream stalls in long-running sessions without message_stop event

Independent second confirmation on macOS arm64 + complementary OpenClaw-side observation.

Hitting the same SSE mid-stream stall pattern, identical claude version (2.1.119), but on a different OS (macOS Tahoe, arm64). Different invocation path: claude is being spawned as a subprocess by OpenClaw 2026.4.24 with claude -p --output-format stream-json --verbose --permission-mode bypassPermissions ... rather than the interactive REPL.

What I observe (concurs with #54434)

When the stall fires:

• lsof -p <claude_pid> shows TCP api.anthropic.com:443 ... ESTABLISHED with zero bytes flowing
• sample <claude_pid> shows the main thread parked in kevent64 (Bun event loop idle, waiting on I/O)
• The CLI's stderr produces zero output during the stall — the silence is the smoking gun
• No message_stop event, no error event — exactly as KingPin reports

I separately ruled out the Datadog telemetry endpoint (http-intake.logs.us5.datadoghq.com) by /etc/hosts blackholing it and observing identical wedge behavior afterward — lsof post-block confirmed only the Anthropic socket was ESTABLISHED. The hang is definitively on the Anthropic SSE stream, consistent with KingPin's repro.

Complementary observation from the OpenClaw side

OpenClaw's gateway has a per-process watchdog (noOutputTimeoutMs, default 180000 ms with a 180s floor) that kills the claude subprocess if no stdout arrives for the configured duration. So in our setup the stall doesn't surface to the user as a frozen UI — it surfaces as CLI produced no output for 180s and was terminated. (timeout) and a FailoverError to the next model. The user-visible symptom is "every model in the fallback chain returns 'all models failed', taking 13 minutes total" rather than KingPin's "spinner forever, ESC to recover."

We patched the OpenClaw watchdog floor down to 60s to shrink the user-facing pain to ~3 minutes (full chain walk through 5 models × 60s each), at which point we were going to file an upstream issue here — but #54434 already nails the root cause and #25979 has the same symptom with a different invocation path. Adding our data instead of opening a duplicate.

Important caveat against aggressive client-side timeouts (relevant to anyone considering a workaround)

KingPin's data shows most stalls naturally recover at 50–70s (51.8s, 67.6s in his table). Aggressive client-side timeouts below ~75s will amputate naturally-recoverable stalls, not just terminate unrecoverable ones. We're seeing this trade-off in our 60s OpenClaw watchdog — some terminations are likely killing streams that would have self-resolved within another 10s. For the proper fix path: a per-chunk read timeout in claude's HTTP client at ~120–180s (well past the natural recovery window) would catch genuinely-stuck streams without false-positive termination of slow-but-recovering ones.

Suggested fix shape (concurs with #25979's "1.")

Add a per-chunk SSE read timeout to claude's HTTP client (Bun's fetch / SSE consumer doesn't impose one by default). On timeout, abort the stream, surface a retryable error with the partial response if any, and let the existing retry/backoff logic kick in. Default of 120–180s would clear the natural recovery window seen in #54434's data while still bounding the worst case.

Happy to share the OpenClaw-side patch (CLI_FRESH_WATCHDOG_DEFAULTS.minMs) and the wedge-sampler script we use to capture stall stacks if useful. Configuration:

• macOS Tahoe (Darwin 25.4.0), arm64
• Claude CLI 2.1.119
• cliBackend.args: ["-p", "--output-format", "stream-json", "--verbose", "--permission-mode", "bypassPermissions"]
• Models tested: claude-opus-4-7, claude-sonnet-4-6, claude-opus-4-6, claude-opus-4-5, claude-sonnet-4-5, claude-haiku-4-5 — all exhibit the same stall pattern, suggesting the issue is in the HTTP client, not model-specific.
• OAuth credential path (Max plan), routed through the cli binary (not direct API)
• CLAUDE_STREAM_IDLE_TIMEOUT_MS not set (using defaults)

This is stream-completion integrity failure.

If SSE streams stall in long-running sessions without a message_stop event, then the product loses the event that tells operators and downstream logic whether a turn actually reached a completed state. That breaks more than UI polish — it breaks the contract around turn finality.

Why it matters:

• users cannot tell whether to wait, retry, or intervene
• clients that depend on message_stop for cleanup or state transitions can hang indefinitely
• long-running sessions become especially fragile because the longer the stream, the more damaging ambiguous completion becomes

I would want clarity on:

1. whether generation completed server-side and only the terminal event was dropped
2. whether the issue is transport idle timeout, server flush behavior, or event sequencing under long streams
3. whether clients have any authoritative fallback to determine completion when message_stop is absent

For agent systems, end-of-turn certainty is part of control. If completion can become ambiguous, every downstream recovery decision gets harder.

this is getting really bad now, with hours of uselessness at a time. havent gotten anything out of Claude in past 3 hours so far. and this is happening for multiple hours every single day now. Intermittent small amounts of output with the majority of the tasks timing out with API Error: Stream idle timeout - partial response received

Reproducing on Linux/Bun with the runtime's stall detector firing as documented.

Environment

• Claude Code 2.1.128 (Bun-backed)
• Ubuntu 24.04.4 LTS, kernel 6.17.0-23-generic
• Terminal: Ghostty
• Workload: interactive multi-turn coding session, --resume

Cadence in a 7-minute window after resuming a long session:

09:43:20  Fast mode unavailable...                          ← heartbeat
                       [ 64.55 s of silence ]
09:44:24  Dynamic tool loading: 10/108 deferred tools
09:46:25  [ 57.05 s gap before this line ]
09:47:25  [ 55.41 s gap ]
09:48:25  [ 53.78 s gap — coincides with: MCP server "notion": HTTP connection dropped after 321s uptime ]
09:49:26  [WARN] Streaming stall detected: 53.6s gap between events (stall #1)

5 stalls in 7 minutes, 53–65 s each, ~60-second cadence — matches your "5 stalls in 26 min, 50–70 s, every ~5 min" almost exactly.

Useful diagnostic technique: the [DEBUG] Fast mode unavailable log fires every ~1 second during normal operation. When the event loop is blocked, the heartbeat itself goes silent — that's a clean signal that the block is event-loop, not network. In our log, every long gap is preceded by the heartbeat as the last line. That suggests at least some of these stalls are client-side (event loop blocked), not purely server-side SSE issues.

Possible upstream cause: at the time of these stalls the umbrella process had VmRSS 6.5 GB and a heap profile consistent with a major-GC working set that takes tens of seconds to mark-and-sweep. Restarting the session (starting from a fresh small heap) eliminates the stalls. Filed leak data in #56335.

This issue may be downstream of the heap retention. Worth checking if a fix to the underlying retention reduces stall frequency.

Adding a much-longer-duration data point that fits your "some never recover" branch — this stall went 7h 58m before manual intervention.

Environment

• Claude Code: 2.1.126 (CLI), running claude --resume <session-id> on macOS 26.x
• Subscription: Claude Max
• Effort level: xhigh (set via /effort max at session start)

Timeline (from the session JSONL)

The hang occurred in a long-running interactive session (ac79b4e9-71ea-4a37-a8ce-03bcff6632df, ~5,265 lines / 12 MB). Excerpting the boundary:

[5246] 2026-05-07T06:05:25.876Z  user        tool_result  (Bash output: ESLint warnings in useRemoteEventListeners.ts)
[5251] 2026-05-07T06:05:25.990Z  pr-link     (CCD/CLI metadata event)
                                 ─── 7h 57m 18s of pure silence ───
[5252] 2026-05-07T14:02:44.594Z  queue-operation  (user-triggered)
[5339] 2026-05-07T14:03:30.359Z  user        text: "Continue from where you left off."

The model had just produced a burst of 6 tool_use calls (5239–5245) — a sequence of grep/awk/Read calls investigating React-hook dependency arrays. The last tool_result came back with the ESLint output, and the model was supposed to take that turn to produce its next response. Nothing came back for 7h 58m. The session JSONL contains zero events in that window — no assistant text, no Sentry capture, no error event, no [Stall] warning, no recovery, no retry. Just a flat gap.

Why this is high-signal for #54434

1. Order of magnitude longer than any case in your table (longest there was ≥120s observed). 7h 58m establishes that there's no upper bound on the "some never recover" branch.
2. No client-side timeout fired — CLAUDE_STREAM_IDLE_TIMEOUT_MS defaults to 900s (15 min) per your environment. If that timer was active here, it should have fired ~32 times. Either the timer doesn't apply to this code path, or it isn't surfacing when it does fire on --resume sessions.
3. No error surfaced to the user — the CLI just sat at a thinking spinner all night. User came back the next morning, found it still spinning, typed "Continue from where you left off." to unstick it. From a UX perspective this is the worst-case manifestation: silent failure with no liveness signal.
4. Same trigger pattern: mid-conversation, immediately after a tool_result, on --resume of a long-running session. Same source=repl_main_thread code path you identified.

Differences worth flagging

• xhigh effort is in play here. Could be that the higher-effort path has a different stall behavior or different timeout discipline. Worth checking whether the affected code path differs between effort levels.
• No [Stall] warnings logged. In your reproduction, [Stall] stream_idle_partial fired every 15s during the wait. In this session's JSONL, no such warning appears at all — but I'm reading from the JSONL, not the debug log, so it's possible the warnings exist there. Will retrieve and update if found.

Cross-references

• This corroborates #56860 (spinner-forever on Windows) and #55308 (mid-task hang causing token reuse on resume) as likely the same underlying SSE stall observed across platforms.
• Distinct from #55241 and #52995 which are --resume startup hangs (don't return to prompt), not mid-session stalls.

If maintainers want the full session JSONL for diagnostic purposes, happy to share it directly via support — it's 12 MB and contains private repo paths so I won't attach here.

Bonus data point in the same thread: while I was drafting the previous comment, the desktop app (CCD) had its own ~2h SSE stall on the same workflow. So this isn't CLI-specific — same bug, same protocol, both client surfaces.

Environment

• Claude Code Desktop (CCD): 2.1.121 (renderer), CLI binary 2.1.126
• macOS 26.x
• Subscription: Claude Max
• Different session from the 8h CLI hang in my prior comment — totally separate workflow, separate session JSONL

What was happening when it stalled

Investigating the previous CLI hang (this issue's repro). Sequence of recent activity right before the desktop stall:

1. Ran gh issue list and gh search shell commands to find related issues — all returned successfully
2. Ran gh issue view 54434 --json body and gh issue view 55241 --json body in a single Bash invocation — output streamed back fine, ~4 KB total
3. Was preparing to draft a comment to post here

That's where the SSE stream stalled. The desktop client sat at a "Thinking…" indicator for ~2h with no token output, no error, no recovery, no Sentry capture. User had to type a new message ("you just got stuck for 2 hours, wtf?") to interrupt and re-prompt — at which point the response came back immediately.

Why this matters for triage

The 8h CLI case from my previous comment + this 2h desktop case are same bug, same trigger pattern (mid-response stall after tool_result), two different client surfaces. So the fix can't live in either client alone — the silent-stream behavior is upstream of both, in the SSE pipe from /v1/messages. That tracks with this issue's diagnosis (server-side worker holding tokens before flushing, occasionally dropping the rest).

Practical UX consequences worth surfacing:

• CLI: spinner forever, no error, no liveness signal. User loses an entire night of work before noticing.
• Desktop: "Thinking…" indicator forever, no error, no liveness signal, no Sentry event (this is distinct from the renderer-crash Sentry pattern in #54369 / #55220 — those fire Main webview render process gone; this one fires nothing at all).

In both cases, neither client surfaces the stall to the user despite Claude Code's own [Stall] stream_idle_partial telemetry detecting it server-internally. An ESC-equivalent prompt or "stream idle for >Ns, want to retry?" affordance would prevent the worst-case workflow loss even if the underlying server-side fix takes longer to land.

Reproducing this on Windows 11 with the Claude Code VS Code extension. Same fingerprint as the original report, different platform, with multi-network confirmation that rules out the network layer entirely.

Environment

• Windows 11, desktop machine
• Claude Code version: 2.1.142.2af (VS Code extension, cc_entrypoint=claude-vscode)
• Standalone CLI version: 2.1.88 (npm-global via nvm, Node 24.13.1) — same stall behavior in both
• Auth: claude.ai OAuth (Max plan), not API key
• Models tested: Opus 4.7 (default), reproduces identically

Symptom

Fresh session, zero files in context, single prompt. Stream starts normally, receives ~650 bytes, then goes silent. [Stall] stream_idle_partial warnings fire every 15 seconds. Connection stays open. No error surfaced.

Key detail: the time-to-first-stall is mechanically consistent at 15.003 seconds across every test — same to the millisecond on three different networks.

Log excerpts (three separate sessions, three different networks)

Ethernet, NordVPN on (source IP 10.5.0.2):

05:23:16.817Z [DEBUG] Stream started - received first chunk
05:23:31.820Z [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15003 bytesTotal=630

Ethernet, NordVPN off (source IP 192.168.0.88, direct via ISP):

05:32:38.204Z [DEBUG] Stream started - received first chunk
05:32:53.207Z [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15003 bytesTotal=653

T-Mobile mobile hotspot, NordVPN off (IPv6 source, completely different ISP/path):

05:58:27.889Z [DEBUG] Stream started - received first chunk
05:58:42.903Z [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15015 bytesTotal=645

All three: fresh session, tracking 0 files, autocompact: tokens=[REDACTED] level=ok, same prompt.

What was ruled out

• ✅ Network path (3 different networks, identical 15.003s timing)
• ✅ ISP (Sparklight cable + T-Mobile cellular both reproduce)
• ✅ VPN (NordVPN on vs off — identical behavior)
• ✅ NordVPN Threat Protection Pro (paused — no change)
• ✅ Modem (Hitron CODA-5712, firmware 7.3.5.1.2b23 — bypassed via hotspot)
• ✅ Claude Code version (updated mid-test from 2.1.141 to 2.1.142.2af — no change)
• ✅ Session length / context size (fresh session, 0 files tracked, well under autocompact threshold)
• ✅ Windows Defender Network Protection (EnableNetworkProtection: 0)
• ✅ Third-party AV (none installed)

curl.exe -v -I https://api.anthropic.com/v1/messages returns 405 in ~200ms on every network tested. The API endpoint is reachable; only long-lived SSE streams stall.

Additional observations

• bytesTotal is consistently in the 630–666 range across all stalls — suggests the stream dies after roughly the same initial burst regardless of prompt or network.
• ALPN consistently negotiates http/1.1 (Windows schannel via curl) — unclear if the SDK negotiates differently.
• Stream started - received first chunk always fires 2–3 seconds after request — initial RTT is fine.

Client request IDs

For correlation:

• 9e7cc463-3c86-4f0b-8fa4-7fbbd9952acb
• 29afebe7-4802-4f33-afb6-d70ec662776e
• 6ae2e8cf-e386-4ac7-9697-92e3bc5a9c21
• 5d7e0230-a30e-4ffa-a070-b5a7d10af471
• 212baedd-aee0-4121-90ab-48c97de23ed2

Happy to provide full debug logs, additional traces, or test specific theories. The multi-network confirmation took some effort to set up but the result is unambiguous: this is not a client-side network issue.

Still seeing this, every request stalls 90s then retries successfully. Fresh session, no context bloat.

Request IDs from this morning (UTC):

7fd8ae54-022e-4262-ab98-b8d300d13f5b 13:04
989186af-9743-43de-9fe1-8be52a6e3a6d 13:06
cf1745c0-914f-4b48-94d7-f68ace4bf99e 13:21

Platform: macOS, VS Code extension, cc_entrypoint=claude-vscode, Max plan OAuth

Been days of this with any use of Opus 4.7 in the Claude VSCode plugin. Doesn't matter if it's a simple or complex task, things hang for huge amounts of time with every prompt. While they do eventually finish sometimes, Claude's output just shows an endless stream of this with the stall time compounding to be longer and longer each time:

2026-05-24 13:41:51.278 [info] From claude: 2026-05-24T17:41:51.279Z [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15005 bytesTotal=660 idleDeadlineMs=300000

2026-05-24 13:42:19.674 [info] From claude: 2026-05-24T17:42:19.675Z [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15001 bytesTotal=696 idleDeadlineMs=300000

2026-05-24 13:42:42.772 [info] From claude: 2026-05-24T17:42:42.774Z [WARN] Streaming stall detected: 66.5s gap between events (stall #1) 

Possibly related: #63880 reports the same delayed-delivery shape from the client side — Bash tool results coming back as (Bash completed with no output) and then flushing in a later batch, which lines up with the "server holds tokens, then flushes late" mechanism described here.

Grepping my local CLI transcripts for that empty-output signature turned up 222 occurrences across 43 sessions, spanning CLI 2.1.112 → 2.1.158 — so this isn't a recent regression. The cost when it isn't caught early is significant: the empty returns read as a stalled session and trigger retry round-trips (one of mine ran ~90 assistant turns over ~9.5 min before self-terminating). The client-side read-timeout/stall-detector asked for in #25979 would bound that. Can share transcript excerpts if useful.

Also hitting SSE stalls on long sessions — the 8-hour one in the comments really resonates. I wrote a watcher called claude-tmux-dog (https://github.com/SnowAIGirl/claude-tmux-dog) that monitors session liveness and token usage, and auto-recovers when the stream goes quiet. It is event-driven (Claude Stop hook triggers recovery flows), handles compaction, quota nudge scheduling, and gives you a pm2-style status view so you can see at a glance whether your session is actually stuck or just thinking. Has been handling my multi-day sessions without manual intervention.

Data point that isolates this to the client, since my setup has zero Anthropic infrastructure in the request path at all.

Setup: Claude Code CLI 2.1.201 pointed entirely at a self-hosted model, not the real API:

ANTHROPIC_BASE_URL=http://127.0.0.1:11434
ANTHROPIC_AUTH_TOKEN=ollama

127.0.0.1:11434 is a local Ollama instance on the same machine, serving gemma4:26b (custom tag gemctx-262144, num_ctx 262144) through llama-server on a second loopback port. There is no network hop, no api.anthropic.com, no Anthropic-side inference worker anywhere in this path — the entire "backend" is a single GPU in the same box: an ASRock Radeon AI PRO R9700 Creator, 32GB VRAM, ROCm 7.2.4, gfx1201.

What happened: a long autonomous coding turn (89 messages in the session transcript, turn_duration logged at 1,864,608 ms ≈ 31 min). Partway through, the CLI's thinking/status line stopped advancing — no new output, no error, spinner just sitting there — for several minutes. It didn't crash, and sending a follow-up message ("continue") resumed it immediately.

What I checked while it looked stalled: ps aux and rocm-smi on the host, at the exact moment the CLI appeared frozen, showed that the llama-server process was still alive and healthy. Claude just wasn't sending it any requests.

Why I think this is worth adding here: since there's no Anthropic-side server, network, or inference worker involved in my setup at all, a stall like this can't be explained by a server-side token-withholding/flush issue — there was no in-flight request for a server to stall. The backend was alive and idle, waiting; the CLI simply stopped dispatching the next request. That points at the client's own request/event-loop handling losing track of the turn, independent of what's actually serving the tokens — which lines up with the event-loop/heap-pressure theory raised earlier in this thread rather than the original server-side theory.

I can reproduce this on Windows as well, both in the CLI and the VS Code extension. It's very intermittent.

Additional data point — macOS, agent-mode, recurring; input silently dropped during the stall

Seeing this repeatedly on macOS (Darwin 25.5.0), Claude Code 2.1.197 (watchdog on), desktop 1.18286.0, model Opus 4.8, local agent-mode + ~11 MCP servers.

Symptom during a stall:

• Transcript JSONL stops appending for 6–10+ min; last entry is a completed stop_reason: end_turn.
• claude process alive but idle (~0–1% CPU), not crashed.
• New user input is silently dropped — typed messages never enter the transcript and are never processed; the spinner never clears.
• Only recovery is starting a new session to take over.

The watchdog (#37080) doesn't catch this case — the turn had already ended cleanly, yet the session no longer ingests input. Happy to attach a ps snapshot + transcript mtime gap, or repro under --safe-mode to isolate MCP involvement.