Thinking block skipped on first response after context compaction, causing critical context loss

[ppravdin]

Description

After context compaction (or session continuation from a compacted conversation), the model's first substantive response can be generated without a thinking block. This causes critical task qualifiers and nuance from the summary to be dropped, even though the compaction summary correctly captured them.

Reproduction

1. Have a long conversation with detailed task context (e.g., working on a multi-step task where specific qualifiers matter — like "create X for Y" where "for Y" is essential)
2. Let the context compact / continue the session from summary
3. The compaction summary correctly preserves the full task description including qualifiers
4. Ask a question that requires the model to reason about what to do next
5. The model produces a response with no thinking block
6. Without the thinking step, the model drops qualifiers and defaults to a generic/surface-level interpretation of the task

Expected Behavior

The model should always use a thinking block when responding to substantive questions after context compaction, especially when the response involves decision-making. The thinking block is where the model would re-read the summary, extract the relevant details, and reason about the correct course of action.

Actual Behavior

The first response after compaction has no thinking block. The model appears to pattern-match on the surface level of the question without reasoning through the compacted summary's details. Critical qualifiers (that were correctly preserved in the summary) are silently dropped.

Impact

This is a high-impact bug because:

• Context compaction happens in long, complex sessions — exactly the sessions where task details are most nuanced
• The summary does its job correctly (details are preserved), but the model fails to use them
• The user has no way to know the model skipped its reasoning step
• The resulting action can be the opposite of what was intended (in our case, the model executed a task with inverted parameters compared to what the summary specified)

Possible Cause

This looks like it could be intentional behavior — "skip thinking on the first message of a new/compacted session" as an optimization. If so, it's a dangerous optimization because the first message after compaction is precisely when thinking is most needed — the model has just lost its full context and needs to re-orient from a summary.

Environment

• Claude Code CLI
• Model: claude-opus-4-6
• Long multi-step session that triggered automatic context compaction

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Thinking mode disabled for first response after skill/slash command invocation #21919
2. Thinking block not generated despite thinking mode being enabled #18305
3. Post-compaction behavior aggressively resumes implementation without assessing conversational context #14941

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

[wagabondpets]

When I'm mid-plan, if it compacts, it comes out of the compacting and starts executing the existing fragment of the plan (which apparently is never saved to /Users/USERNAME/.claude/plans/ now and just comes out of the window?!?!) without any input.

It literally takes itself out of plan mode into auto accept.

[ppravdin]

This is not a duplicate of any of the suggested issues.

• [BUG] Thinking mode disabled for first response after skill/slash command invocation #21919 is about thinking being disabled after slash command/skill invocation. This issue is about thinking being skipped after context compaction. Different trigger, different code path.
• Thinking block not generated despite thinking mode being enabled #18305 is about thinking not generating despite being enabled. Generic symptom, different cause. Our issue has a specific, identified trigger: context compaction → first response → no thinking block.
• Post-compaction behavior aggressively resumes implementation without assessing conversational context #14941 is about post-compaction behavior resuming implementation aggressively. Related symptom but different root cause — that issue is about the model acting without user input, this issue is about the model not thinking when it does act, causing it to drop critical context qualifiers from the compaction summary.

The specific bug here: after context compaction, the summary correctly preserves task details (verified by reading the JSONL transcript). But the model's first substantive response has no thinking block, so it pattern-matches on the surface level of the user's question instead of reasoning through the summary. This caused it to execute a task with inverted parameters compared to what the summary specified.

This is a distinct, reproducible issue with a clear forensic trace from the conversation transcript.

[scapeshift-ojones]

This is related to the hidePastThinking: !0 hardcoding documented in #27242 (Bug 1) and #16965. Compaction doesn't just hide thinking blocks in transcript mode — it apparently can cause them to be skipped entirely on the first post-compaction response.

The broader problem tracked in #27242: three separate scenarios where conversation context becomes inaccessible after compaction, plan-mode clear, or branch navigation — all with data preserved in JSONL but no TUI to view it. If compaction-related context loss affects your workflow, please 👍 and comment there.

[ppravdin]

@scapeshift-ojones Thanks for tracing this to hidePastThinking: !0. That explains the mechanism — if compaction tells the model to suppress thinking, and the first post-compaction response is the one where the model most needs to reason through the summary to re-orient, you get exactly what we observed: the model acts on a surface-level reading of the user's question instead of reasoning through the compacted summary's details.

In our case the summary correctly preserved a task description with a critical qualifier (e.g. "do X for Y"), but without a thinking block the model produced a generic response that dropped the qualifier and executed the task with effectively inverted parameters. The data was right there in the summary — the model just never reasoned about it.

This means the fix isn't just "show thinking in the UI" — hidePastThinking is apparently causing the model to not think at all on the critical first response after compaction. That's where thinking is most needed, not least.

Upvoted #27242.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.