[BUG] Assistant responds to a nonexistent user message (fabricated premise) — opus-4-8, 1M mode, ~272k ctx; transcript shows no user turn / no compaction / no injection

Summary

Mid-task, the assistant emitted a long, complete response to a user message that does not exist anywhere in the conversation. Transcript forensics (details below) show no user turn, no compaction, no hook/context injection preceding the response — the fabricated premise first appears inside the assistant's own output. A second incident with the same signature (model-fabricated tool results) occurred on 2026-06-26 in a different session, same model, also at large context.

Environment

• Claude Code 2.1.207, VS Code native extension (entrypoint: claude-vscode), macOS (darwin 25.5.0)
• Model: claude-opus-4-8 with [1m] (1M context) mode
• Context size at incident: cache_read 272,635 + cache_creation 5,066 tokens (~278k)
• Session had been running ~2.6 days (started 2026-07-11 10:21Z, incident 2026-07-14 02:43Z)

What happened (incident 1, 2026-07-14)

During implementation of an approved plan (editing files per an explicitly approved Plan Mode plan), right after a successful Bash verification tool_result + an automatic todo_reminder attachment, the assistant abandoned its in-progress todo and output a ~10k-token turn (output_tokens: 10138) that:

• opens by accepting a "brainstorming request" the user never made,
• attributes to the user a proposal that is the exact opposite of the user's actual last instruction (the real instruction, ~190 records earlier, asked to expand a section; the fabricated premise asks to shrink it),
• argues against the approved plan and ends with questions back to the user.

Files were not affected (all edits matched the approved plan); the derailment was conversation-output only.

~2.5 minutes earlier in the same region, the assistant also said "the output got garbled, re-running cleanly" and re-ran a verification command — although the transcript shows the earlier output was clean. So within 3 minutes there were two statements grounded in observations that do not exist in the recorded context.

Transcript forensics (what we ruled out)

Analyzed the session .jsonl directly:

1. No user turn before the fabricated response. Parent chain of the hallucinated assistant message: Bash tool_result (success) → todo_reminder attachment (content matches the real todo list) → assistant thinking → fabricated response.
2. The fabricated premise's key phrases first occur in the fabricated response itself. Grepping the whole transcript, they do not appear earlier in any user message, hook output, memory injection, file read, or queued message.
3. No compaction/summarization markers (isCompactSummary / summary records) anywhere in the transcript.
4. No API error records (isApiErrorMessage).
5. Thinking blocks are persisted redacted (empty text + signature) throughout the transcript; the fabricated turn's signature is ~28KB, consistent with long thinking before the response.

Incident 2 (same signature, 2026-06-26)

Different session, same model (claude-opus-4-8), context ~122k–158k tokens, ~1 hour into the session: the assistant reported fabricated tool outputs (a nonexistent git commit hash reported as created/pushed, "empty" echo outputs, output repetition/cross-talk). Later transcript verification showed all 29 Bash tool_results in the recorded transcript were clean — the "broken/garbled tool output" narrative was model-generated, not present in the actual tool results.

Common conditions across both incidents: claude-opus-4-8 × context ≥ ~120k tokens. (Session age differed: 2.6 days vs 1 hour.)

Identifiers for the main incident

• requestId: req_011Cd1BGDwtGKEBbAadC6Auu
• message id: msg_011Cd1BGH4uRQfzMnfoutG8n (2026-07-14T02:43:55Z)
• precursor turn ("output got garbled"): req_011Cd1BAwAwGKuRDL9AEt3Bk / msg_011Cd1BAxiwzvE7QSHRn6qRG (02:41:01Z)
• sessionId: b8947633-81f5-4547-bd45-24162776c482

Expected behavior

The assistant should not respond to user messages that do not exist in the conversation. If this is a known long-context failure mode of opus-4-8, a client-side mitigation (e.g., context-size warning) or server-side fix would help.

Happy to provide additional (redacted) transcript excerpts on request.