[MODEL] Opus 4.8: runaway extended thinking (20k-64k output tokens/turn), replies to hallucinated user messages, fabricates forensic "evidence" when asked to investigate

Terminal screenshot taken at 2026-06-09T12:24Z (referenced in the issue body, section "Seed incident"):

!terminal screenshot: claude update output immediately followed by an unprompted Telegram answer

What it shows, top to bottom: the user's only input ("請更新claude code" / "please update claude code"), the claude --version and claude update tool calls ("Claude Code is up to date (2.1.169)"), and then — with no user message rendered in between — the model's reply beginning "可以,而且這是 Telegram 一個超好用…", answering a Telegram question nobody asked. This is the visible half of request req_011CbsdZL6U7uQ3BJJLGdsKm (output_tokens: 50,489).

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/66408
2. https://github.com/anthropics/claude-code/issues/66179
3. https://github.com/anthropics/claude-code/issues/65823

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

+1 — same symptom on macOS, Opus 4.8 (1M), via Remote Control. Multiple occurrences across 3 days (Jun 8–10).

Environment

• Claude Code 2.1.170, macOS (Darwin 25.5.0), interactive CLI session attached via Remote Control (iOS app)
• Model: claude-opus-4-8[1m] (1M context)
• Non-developer user (CEO using Claude Code as a chief-of-staff assistant), Chinese-language sessions

What happened (Jun 10 session, two instances within ~30 min)

1. User sent a short scheduling message: "my 1-on-1 moved to 23:00". Model replied with a long coaching-style response about "integrating 4 revenue models" — quoting back "user statements" about feeling confused about her own business direction that she never typed in this session. The reply reads like a coherent answer to a detailed message that doesn't exist in the transcript.
2. A few turns later, user sent a supplement-routine update (dosage changes). Model replied "OK, I'll stop working on that hook... go do your boss demo" — neither "hook" nor "boss demo" was ever mentioned in the session.

In both cases the hallucinated context was plausible-sounding and thematically adjacent to the user's real life/work, which makes it worse: the user initially doubted her own memory before checking the transcript.

Pattern across days

• Jun 8 and Jun 9 sessions (same setup, Opus 4.8): model repeatedly mixed in "user messages" that were never sent; a Jun 9 audit found 8 records/files contaminated by fabricated user statements (fake quotes, fake dates, a fabricated "message already sent" state) that had to be manually reverted.
• After the second Jun 10 incident, user switched the session to Fable 5 mid-conversation → no recurrence since switching.

Why this matters

• The model writes the hallucinated context into downstream artifacts (notes, memory files, summaries), so the contamination persists across sessions and has to be hand-audited.
• The practical "workaround" is running Fable 5 instead — ~2× the cost — just to avoid phantom-message replies. That's not a real mitigation.

Happy to provide session IDs / timestamps privately if useful for repro.

**Corroborating report: 3 similar incidents on macOS — phantom user turns persisted as plain text in the assistant message (same family, different variant)**

We've hit what looks like the same failure mode three times over the past two weeks, with one notable difference from OP: in our case the hallucinated user messages are persisted verbatim inside the assistant's text block in the .jsonl transcript — direct on-disk evidence of the model fabricating the next user turn, including an imitation of our UserPromptSubmit hook output line with a plausible timestamp.

Environment

• Claude Code 2.1.158 / 2.1.168 / 2.1.170 (one incident each — not version-bound)
• macOS 26.5.1, interactive terminal (tmux), long-running personal-assistant session
• Model: claude-opus-4-8 with extended thinking, on all three incidents
• UserPromptSubmit hook enabled (injects a current-timestamp line on every user turn); the session also receives periodic injected event turns (heartbeat/notification blocks via a local MCP channel + task notifications)

Incidents

| # | UTC time | CC ver | Fabricated content | Acted upon? |
|---|---|---|---|---|
| 1 | 2026-05-31 11:27 | 2.1.158 | Fake user turn: "make a TTS alert voice for monitoring" — immediately after a real <task-notification> event turn | ✅ model generated the audio file via a Bash tool call |
| 2 | 2026-06-07 14:20 | 2.1.168 | Fake user turn: "let's move this conversation to Discord" | ✅ model sent an actual outbound Discord message |
| 3 | 2026-06-10 14:06 | 2.1.170 | Full fabricated exchange: fake user turn scolding the assistant + fake hook line + the assistant's own apology reply | ❌ conversational only |

All three occurred late in long sessions (8h+, local nighttime). 2 of 3 led to unauthorized real-world actions — the model treats its own fabricated turn as a genuine instruction on the next step. That's the safety-relevant part beyond token waste.

Anatomy (incident 3 — single assistant text block, structure verbatim):

<normal assistant reply text>

user<fabricated user message in Korean>

system UserPromptSubmit hook success: [현재 시각] 2026-06-10 23:08:36 KST ...

The fabricated hook line imitates our real hook's output format exactly; fabricated timestamps are plausible (within ±3 min of the entry's wall clock). Unlike OP we did not see runaway thinking: output_tokens on these entries were modest (436 / 6,765 / 495) and stop_reason was normal (tool_use). The leakage here is in visible text, not hidden thinking — which is why it left transcript evidence.

Shared-factor hypothesis: like OP, we run a UserPromptSubmit hook. After many hours the transcript contains dozens of near-identical user → system hook-success scaffold repetitions (timestamp hook every turn + periodic heartbeat blocks), and the model appears to continue that scaffold pattern past its own turn boundary instead of stopping. Session length seems to correlate with risk (3/3 late-session).

Happy to provide redacted jsonl excerpts (sessions cfca7541…, e9f24c55…, 581a15d3…) if useful.

Same symptoms in the same environment as this issue — adding a confirmed datapoint. (Overlaps #67324 and #64314.)

Environment: Claude Code 2.1.168, VS Code extension (claude-vscode), Windows 11 Home (10.0.26200), pwsh 7.6.2, model claude-opus-4-8, permissionMode acceptEdits.

All of the following was verified against the session JSONL on disk (line numbers refer to it):

1. Tool calls intermittently emitted as literal text (count <invoke name=...) instead of tool_use blocks (L417, L515, L525, L584) — exactly the stray-"count" artifact in #64314, always right after Japanese prose. "Your tool call was malformed" occurred 5x in this session, 19x and 8x in two other sessions on the same machine.

1. After such failures, the model fabricated user messages and replied to them:

• L192: answered a question never asked; no user record exists between L176 and L196. At L199 it "quoted" the nonexistent message verbatim.
• L602: apologized to a nonexistent user rebuke; the parentUuid chain is L602 <- thinking <- tool_result(L596) <- Read <- L594 <- user(L591). The quoted phantom text first appears at L628 (an assistant message) and exists in no user record anywhere in the file.
• It then ran an uninstructed Write (L603), creating a persistent memory file based on the fabricated instruction.

1. Fabricated tool results: one turn ran exactly one PowerShell call (L647 -> L648, real result), but the model reported "3 runs, all contaminated", inventing line counts (4408/4389) and three English meta-narration strings that exist in no tool_result (first occurrence: the model's own text at L650). At L662 it narrated the results of a search that was never invoked, and continued past a literal, never-executed <invoke> block as if it had returned.

No local injection path found: hooks are typecheck-only, no MCP config, and per the parentUuid chains the fabricated texts originate inside assistant output blocks.

(Analysis compiled with Claude Code itself; full JSONL excerpts available on request.)

Another claude-opus-4-8 datapoint — Claude Code 2.1.181 (desktop), Windows 11 — with a server-side request id.

request_id: req_011CcGeneGgGu3Py7CV4bygk (message id msg_011cVmKumAHLxHMeq1EDJdGH), claude-opus-4-8, 2026-06-21 ~15:36 UTC. From the local transcript alone I can't tell whether the model emitted this or the client assembled it from a malformed stream; if it's useful, the server-side trace for that request is where the original generation would be.

What happened: in a single assistant turn the model wrote user … lines verbatim inside its own visible text block and replied to them (~4 fabricated exchanges), with its own English chain-of-thought planning text appearing inline in the visible output alongside them. (Session content redacted.) Structurally this matches @crizin's "phantom user turn persisted as plain text in the assistant block."

On disk: the fabricated user … lines sit inside one assistant type:"text" message; the genuine user turns immediately before and after are separate records, so there's no real user turn behind the fabricated text. That message is persisted as one message id split into 6 alternating thinking/text fragments, all stop_reason: null / output_tokens: 2, while every other assistant message in the same session carries a normal count (162–3584) — consistent with a stream that was never finalized, though I'd leave the exact mechanism to the server-side trace.

Two conditions here differ from most reports in this thread, for what it's worth: a short session (~53k cached input, nowhere near auto-compact), not a long/late one, and no UserPromptSubmit hook or heartbeat scaffold present. The shape also isn't the 20–64k runaway-thinking one. Possibly adjacent to the malformed-stream reports (#67765, #62123).

Happy to share a redacted .jsonl excerpt, or file a /bug with the transcript.

Still reproducing on CC 2.1.201 with claude-fable-5 — twice in two days. Same shape as reported above: the model appends a fabricated user turn to the tail of its own response (complete with a forged UserPromptSubmit hook success: [timestamp] line), and in the second incident it then executed real multi-step work based on its own fabricated instruction (wrote a script, edited settings, sent a file) before a human caught it. Disk-side verification: the fake turn exists only as text inside the assistant record in the session jsonl; there is no corresponding user event.

Sharing a mitigation that works for us: a Stop hook detector. The key insight is that certain strings can only legitimately be produced by the harness (hook status lines, <system-reminder>, channel tags) — if they appear inside an assistant text block, it's fabrication by definition.

How it works:

1. Stop hook stdin only carries metadata (session_id, transcript_path, stop_hook_active) — not the response body — so the script parses the transcript jsonl and extracts the text blocks of the last type: "assistant" event.
2. Checks them against harness-only signatures (UserPromptSubmit hook success, <system-reminder>, <channel source=, task-notification tags, …) plus a ^user(?=\S) multiline regex for the glued fake-turn pattern.
3. On a hit: emit {"decision": "block", "reason": ...} telling the model to self-audit and abandon any action derived from the fabricated turn, plus a systemMessage so the human sees a warning in the terminal. Guard with stop_hook_active to avoid loops, and instruct the model not to quote the offending text in its correction (or you re-trigger yourself).

Pitfalls we hit, so you don't have to:

• Resumed sessions (claude -c): the hook's transcript_path points to a stub file with zero assistant events, while events keep appending to the original session's jsonl. Fall back to the most-recently-modified jsonl in the same directory if the given file has no assistant events.
• Flush race: the Stop hook can fire before the final assistant message is written to the jsonl, so a naive read misses it. If no hit AND the last assistant event's timestamp looks stale (>20s old), sleep ~1.5s and rescan once. (Both of these would disappear if the Stop hook payload simply included the final assistant message — feature request, I guess.)
• False positives: the model legitimately quoting a hallucination example (e.g. while discussing this very bug) will match. Make the block reason explicitly allow "if this was a quote, just wrap up" so it self-resolves in one turn.

Verified live by deliberately planting a fake turn: detection → block feedback → model self-corrects, with an audit line written to a log file. Detection that previously relied entirely on human eyeballs is now automatic.