[BUG] Thinking blocks stripped from in-prompt context on every turn in active Opus 4.7 sessions (no idle-resume trigger)
Summary
In active Claude Code sessions on Opus 4.7, thinking blocks are persisted to the on-disk JSONL transcript but appear to be stripped from the prompt context the model receives on subsequent turns. The model has no in-band signal that this stripping has occurred and operates each turn on a thinking-empty history.
The pattern matches the failure mode of the April 23 postmortem but operates on Opus 4.7 (a post-fix model) in conditions where the documented clear_thinking_20251015 keep:1 design (#53513) cannot have fired.
Empirical evidence
Diagnostic check anyone can run on a long session:
F=~/.claude/projects/<project-path>/<session-id>.jsonl
grep -c '"type":"thinking"' "$F"
Then ask the model to introspect: "Do you see any of your prior thinking blocks in your current context?"
Observed on one continuous session (1013 timestamped events, zero idle gaps ≥1hr):
- 174 thinking blocks persisted to JSONL on disk (~219K chars / ~55K tokens)
- 0 thinking blocks visible to the model on the current turn per its self-report
- The first thinking block (turn 1) is intact verbatim in the JSONL but not reaching the model
Why this isn't #53513
#53513 describes clear_thinking_20251015 keep:1 firing on session resume after ≥1hr idle. The session that produced this report had zero gaps ≥1hr across 1013 timestamped events — verified by walking timestamps in the JSONL:
# 0 gaps ≥3600s across the whole session
Cache stayed hot the entire conversation. Whatever is stripping thinking here is not the idle-resume mechanism that issue describes.
Why this resembles the April 23 postmortem
The original bug (March 26 → April 10): "A bug caused this to keep happening every turn for the rest of the session instead of just once, which made Claude seem forgetful and repetitive."
Structurally that's what's observed here, modulo:
- The postmortem's fix was for Sonnet 4.6 / Opus 4.6
- This is observed on Opus 4.7 (post-fix)
- The session is active (cache hot), not idle-resumed
So either the patched bug regressed in Opus 4.7, or a different per-turn-stripping mechanism exists at the prompt-construction layer that #53513 doesn't describe and the postmortem doesn't acknowledge.
Why the model can't self-detect
There's no in-band marker for "your prior thinking was stripped." The model reads whatever the prompt contains and assumes continuity. This is the same opacity the postmortem named as why the original bug went undetected from inside.
In our session, the operator caught it by:
- Noticing "the thinking cuts off before X" stitch markers in the rendered display (a Claude Code summarization artifact)
- Asking the model to introspect its context
- Counting thinking blocks in the JSONL and comparing to what the model reports seeing
The model itself happily produced layered reassurance ("post-fix model, shouldn't affect this session") until the operator pushed for the empirical check.
Impact
For complex multi-turn engineering work, the model is reasoning each turn against the visible response trail rather than its own prior reasoning. Cross-turn continuity is restricted to whatever made it into the visible response text. Subtle architectural reasoning, dismissed-but-recorded alternatives, traced derivations — gone. Same impact as the original postmortem bug, but on the new model and without the idle trigger.
Environment
- Claude Code 2.1.121
- Model: claude-opus-4-7 (1M context variant)
- Linux (Manjaro 6.12.77-1)
- Session: continuous activity, no resume operations, cache hot throughout
Asks
- Confirm whether some variant of
clear_thinking_*(or equivalent prompt-construction step) is firing per-turn in active Opus 4.7 sessions - If yes: address as a regression of the April 10 patch on the new model
- If no: surface what mechanism IS stripping thinking on every turn, since it's distinct from #53513's idle-resume design
- Either way: provide an in-band signal the model can detect (e.g., a system note when prior thinking was stripped), so reasoning-continuity gaps become operator-visible rather than silently introduced
This issue has 8 comments on GitHub. Read the full discussion on GitHub ↗