[BUG] Opus 4.8 (1M) stream hangs after first chunk since 2.1.154; 2.1.153 is last known good

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46745
2. https://github.com/anthropics/claude-code/issues/66095
3. https://github.com/anthropics/claude-code/issues/64900

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

Found 3 possible duplicate issues: 1. [[BUG] Claude Code stream dies after first chunk — constant silent stalls, extensive diagnostics attached #46745](https://github.com/anthropics/claude-code/issues/46745) 2. Server withholds stream bytes after accepting request — frequent slow-first-byte and 180s idle-timeout aborts (2.1.157, Opus 4.8) #66095 3. [[BUG] Intermittent mid-stream SSE stall — Opus 4.7/4.8, Sonnet 4.6, pause token emission 40–600s mid-response, latency increasing (VS Code extension) #64900](https://github.com/anthropics/claude-code/issues/64900) 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 don't think this is an exact duplicate.

The linked issues are related, especially #46745 and #66095, but this report adds a specific long-term regression boundary and machine/model comparison:

• 2.1.153 is the last known-good version on this same machine.
• The issue starts at 2.1.154 and still reproduces on 2.1.197.
• I have tested many versions across 2.1.154 -> 2.1.197; each tested version reproduced the same Opus 4.8 hang/misbehavior, and I repeatedly rolled back to 2.1.153.
• On the same machine, Opus 4.7 works normally; Opus 4.8 / 1M hangs or misbehaves.
• The affected machine is an Apple M4 Max; an M1 Pro Mac and a Windows machine do not reproduce the same behavior with the same account.
• I also submitted in-product feedback with session details: Feedback ID ce515f85-8f15-4669-abce-3471ad252167.

So I agree this is likely related to the stream-stall family, but I would like to keep this issue open because it provides a narrower version boundary and hardware/model comparison that may help isolate the regression.

One more narrowing data point:

After 2.1.154, Sonnet continues to work normally on the same affected machine. The regression appears specific to Opus 4.8 / 1M context behavior.

So the pattern is:

• Claude Code 2.1.153 + Opus 4.8: works normally
• Claude Code 2.1.154+ through 2.1.197 + Opus 4.8 / 1M: hangs/misbehaves
• Same 2.1.154+ versions + Sonnet: works normally
• Same affected machine + Opus 4.7: works normally

This further suggests the issue is not a general Claude Code, terminal, network, or account problem, but something specific to the Opus 4.8 path introduced around 2.1.154.

Update: testing 2.1.199 + Opus 4.8 (1M)

Quick status update — I've been running 2.1.199 with Opus 4.8 (1M context) for about a day now, and so far I have not been able to reproduce the stream-hang. Previously the hang would occur within a short session ("not long before it stalls"), so the change in behavior is noticeable.

Caveats before anyone treats this as fixed:

• I don't see any changelog entry in 2.1.198/2.1.199 that names this specific stream-stall-after-first-chunk bug. If it's improved, it may be an indirect effect of the 2.1.199 streaming fix (partial output is now retained instead of being discarded on a mid-stream server error) rather than a targeted root-cause fix.
• This is only ~1 day of observation and I haven't yet stress-tested long conversations, subagents, or extended thinking, which is where it used to surface.

Keeping this open for now until I can confirm it holds across longer sessions. Will report back.

Follow-up: reproduced on 2.1.199 ~1 hour after the previous update — possible link to interrupting model tool_use / subagent calls

Just ~1 hour after posting the previous "not reproduced yet" update, I hit the same stream hang on 2.1.199 + Opus 4.8 (1M). I have a possibly-useful lead this time. Observations first, timeline at the bottom for anyone who wants to dig.

---

Main observation (user-level, from ~1 month of testing):

Throughout my testing across 2.1.154–197, I frequently interrupted the model's tool_use / subagent calls (this is a normal part of how I use Claude Code). Subjectively, I noticed that hangs seem particularly prone to occur after I've interrupted the model. This is user-perceived correlation, not a rigorously proven cause, but the pattern has been consistent enough over several weeks that I think it's worth flagging. Interrupting may not be a necessary trigger, but it does appear to significantly raise the probability of a stream stall.

Today's stall on 2.1.199 matched the same pattern: I interrupted a Skill call that was mid-way through launching a subagent → over the next few minutes the assistant hit multiple stream stalls (91s / 84s / 59s of complete silence) → eventually the session went fully unresponsive.

---

Three side-observations that might help debugging:

1. The model self-reported the anomaly right before dying. In its final text before going silent, the assistant literally said (translated): "the environment output keeps getting polluted — my command echoes and results are interleaving." The model was itself observing that its stream state was off, so this isn't purely external behavior.
2. The tool_result that preceded the final hang contained a Claude-Code-injected notice Shell cwd was reset to <home>. I suspect this is related to shell state being cleaned up after the earlier interrupted subagent/skill.
3. During the hang, the transcript records a "phantom resend" of a user prompt. The same prompt appears twice as independent submissions (different promptId, same parentUuid, 91s apart), but I have no memory of resending it. Could be an unconscious re-tap while the UI was frozen, a duplicate keyboard event, or some client-side resend mechanism — either way, it's an observable side symptom of the hang state and worth noting.

---

Hypothesis:

When a Skill that's mid-subagent-launch gets interrupted, incomplete tool_use / shell state may be left in either the client or the model's context. The model doesn't fail immediately; instead it enters a half-dead intermittent stream-stall state, and eventually stops emitting any events at all after some tool_result. The symptom itself ("stream stops after the first chunk") matches the original issue exactly — but this run adds a suspicious preceding trigger pattern.

---

Detailed timeline (for anyone digging, T = trigger moment, taken from session transcript):

• T: User interrupts a Skill call that was mid-way through launching a subagent
• T + 6s: User sends next prompt ("I want to tweak this skill") → assistant sends a short reply and end_turn — looks normal
• T + 46s: User sends next prompt (about how to redesign the skill) → assistant produces no response at all
• T + 137s: The same prompt is recorded again as an independent submission (user does not remember resending)
• T + 150s: Assistant revives, sends a short text + a Read on the skill's SKILL.md
• T + 150s ~ T + 234s: After the Read tool_result returns, ~84s with no assistant events
• T + 234s: Assistant revives again, emits a chunk of text (containing the "environment output keeps getting polluted" self-report), then calls Bash (git show ...)
• The Bash returns a non-zero-exit git error, and the tool_result carries the Claude-Code-injected Shell cwd was reset to <home> notice
• T + 241s ~ T + 300s: ~59s with no assistant events
• User interrupts manually → sends a new prompt (asking about that "environment output pollution" self-report)
• From this point on the transcript contains no further assistant events at all — no text, no thinking, no tool_use, no error. The session is fully unresponsive and can only be recovered via manual slash commands.

---

Keeping the issue open. 2.1.199 does not fix this bug. No --debug api log this time; I'll capture one next time. Happy to share sanitized transcript excerpts if useful.

Additional data point: restoring the conversation to before the interrupt fully recovered the model, verified across many turns

After the hang event above, I restored the conversation to a checkpoint from before the interrupted subagent call, and continued talking on the same session, same machine, same 2.1.199, same Opus 4.8 (1M). The model immediately recovered to normal behavior, and has since continued to respond stably across many turns with no further stream stalls at all.

This is a fairly clean A/B contrast — the only variable is whether the interrupted subagent call is left in the conversation context:

• With that context present → repeated stream stalls, eventually fully unresponsive
• With that context restored away → immediately normal, and verified stable across many follow-up turns

This rules out "time-of-day coincidence", "transient network hiccup", and "temporary server-side state" as the cause. It strongly supports the inference that the hang does not live in the current machine / network / model-server state, but in the residue that the interrupted subagent tool_use leaves behind in the context itself. Once the context is clean, the same model runs stably.

Suggested direction for debugging: worth checking whether, when a subagent-launching call is interrupted, the client-side conversation history sent to the API is left with an asymmetric structure (e.g. a tool_use block without a matching complete tool_result), and whether Opus 4.8 in 1M-context mode stream-stalls specifically when it encounters that malformed structure.