[BUG] v2.1.69: thinking summaries empty in transcript and TUI — undocumented behavior change

+1 — this broke my workflow as well. I run a custom cognitive architecture that monitors Claude Code sessions in real time by tailing the JSONL. Thinking blocks are critical for understanding why Claude made specific decisions during long agentic sessions. The summarized thinking text was the key piece that made external tooling viable. Happy to see this pinpointed to the 2.1.68 → 2.1.69 boundary.

Can confirm the same issue on macOS + Warp + Max subscription (v2.1.69 and v2.1.70). Tested on two separate Mac machines with the same account — both show thinking_len=0 on v2.1.69+, both restore normal thinking content on v2.1.68.

Detailed findings in #31326.

Can confirm same issue presits on claude code version 2.1.72

Workaround confirmed: The root cause was identified by @anthrotype in #31326 (comment).

Starting in v2.1.69, Claude Code sends a redact-thinking-2026-02-12 beta header with every API request, which instructs the API to strip thinking text from the response. The undocumented showThinkingSummaries setting controls this behavior, but defaults to undefined (which evaluates as redaction enabled).

Fix: Add to ~/.claude/settings.json:

{
  "showThinkingSummaries": true
}

Then restart Claude Code. Thinking summaries will reappear in verbose mode (Ctrl+O).

Same, here I rely on ctrl+o to see the model reasoning to improve how I reason and how the system is constructed. We can no longer see it after 2.1.68. Same issue running with latest 2.1.74.

@qishaoyumu thanks!

+1 — this broke my workflow as well. I run a custom cognitive architecture that monitors Claude Code sessions in real time by tailing the JSONL. Thinking blocks are critical for understanding why Claude made specific decisions during long agentic sessions. The summarized thinking text was the key piece that made external tooling viable. Happy to see this pinpointed to the 2.1.68 → 2.1.69 boundary.

that sounds really cool, care to share?

https://github.com/anthropics/claude-code/issues/8477#issuecomment-4145397185

Still reproducing on v2.1.114 (macOS, Opus 4.7, Claude Max subscription), so this has persisted well past the original v2.1.69 report.

Relevant to the config side — I have both of these explicitly set:

• "showThinkingSummaries": true in ~/.claude/settings.json
• launching with claude --thinking-display summarized

Even with both in place, thinking summaries stay empty in a fresh session.

One data point that might help narrow it down: thinking summaries do appear — but only after I enter plan mode (Shift+Tab → plan mode) at least once in the session. From that point on, thinking blocks in the transcript are populated and rendered in the TUI as expected. In a fresh session where plan mode is never toggled, thinking content stays empty (0 chars), exactly as the OP describes.

Exiting plan mode back to normal mode within the same session does not turn it off again — once triggered, thinking summaries keep coming.

This suggests the regression may be around a conditional flag (interleaved thinking / thinking.type=enabled / summary request) that only gets sent when plan mode is or has been active, rather than unconditionally as in v2.1.68 — and that neither showThinkingSummaries nor --thinking-display summarized currently force it on outside of plan mode.

Same bug on Windows / VS Code extension 2.1.x with Opus 4.7. Not macOS-specific.

Root cause is now public (credit to the workaround in #8477 (comment)): Opus 4.7 changed the API default for thinking blocks from display: "summarized" to display: "omitted". The blocks are still in the response stream, but the thinking field is empty unless the caller passes display: "summarized" explicitly. Documented in Anthropic's own migration guide: https://platform.claude.com/docs/en/about-claude/models/migration-guide#migrating-to-claude-opus-4-7

Net effect: showThinkingSummaries, alwaysThinkingEnabled, and viewMode: "verbose" have nothing to render, because Claude Code does not pass display: "summarized" when calling the Opus 4.7 API. showThinkingSummaries is the documented, official way to surface thinking in the VS Code extension, and it is silently broken on Opus 4.7. The settings surface never caught up to the API change.

Two undocumented workarounds (from the same comment):

1. Add to ~/.claude/settings.json:

``json
{
"env": {
"CLAUDE_CODE_EXTRA_BODY": "{\"thinking\":{\"type\":\"adaptive\",\"display\":\"summarized\"}}"
}
}
``

1. Hidden CLI flag: --thinking-display summarized

The env var approach works for the VS Code extension since it delegates to the CLI.

Why this is high-priority, not a cosmetic regression:

Visible real-time thinking was load-bearing for the steering loop. With it visible, you could stop the model going down a wrong branch before it spent N turns of token budget on a wrong premise; you could verify it had internalized constraints from CLAUDE.md / memory rather than hallucinated them; and you could audit assumptions before committing to a plan.

With it hidden behind an unexpandable pill, you cannot tell whether a wrong final answer came from a wrong premise or a wrong execution of a right premise. Silent assumption drift becomes invisible until after the wrong action is taken. "Thought for 376s" is a duration, not a signal. It tells you nothing actionable. This is a regression in the developer's ability to supervise the agent.

On the user side: this is a paid product. Pro at $20/month, Max at $100–$200/month. Paying customers should not have to monkey-patch cli.js, reverse-engineer an undocumented CLAUDE_CODE_EXTRA_BODY env var, or scrape issue threads to recover functionality that worked in the previous release of the same product. The workaround being undocumented is itself a bug. The gap between what the API supports and what Claude Code exposes as a first-class setting keeps widening with every model bump.

Related open issues, same root problem:

• #8477 — original tracking issue where the API-default change was traced and the workaround was published
• #49268 — harness doesn't set display: "summarized" for Opus 4.7 (same root cause, named explicitly)
• #49757 — empty/unexpandable stub in VS Code extension (Opus 4.7)
• #49902 — thinking summaries not rendered (VS Code extension 2.1.112)
• #49322 — thinking summaries not rendered in VS Code extension (Opus 4.7)
• #48065 — thinking summaries not displayed when showThinkingSummaries enabled
• #49739 — toggle button inverted, no visual feedback (v2.1.112), likely a related UI-state bug
• #51131 — extended thinking dropdown no longer expandable in VS Code extension (Opus 4.7)
• #33163 — "Bring back thinking" feature request, same underlying ask

What would actually resolve this:

1. Pass display: "summarized" by default for Opus 4.7+ when showThinkingSummaries and alwaysThinkingEnabled are on. Or expose a first-class thinkingDisplay setting alongside the existing thinkingEnabled and effortLevel.
2. Restore the expandable thinking block in the VS Code extension chat panel so showThinkingSummaries actually shows summaries when the data is present.
3. Update the docs so they reflect current showThinkingSummaries semantics on Opus 4.7+ instead of describing behavior that no longer applies.

Same bug on Windows / VS Code extension 2.1.x with Opus 4.7. Not macOS-specific. Root cause is now public (credit to the workaround in #8477 (comment)): Opus 4.7 changed the API default for thinking blocks from display: "summarized" to display: "omitted". The blocks are still in the response stream, but the thinking field is empty unless the caller passes display: "summarized" explicitly. Documented in Anthropic's own migration guide: platform.claude.com/docs/en/about-claude/models/migration-guide#migrating-to-claude-opus-4-7 Net effect: showThinkingSummaries, alwaysThinkingEnabled, and viewMode: "verbose" have nothing to render, because Claude Code does not pass display: "summarized" when calling the Opus 4.7 API. showThinkingSummaries is the documented, official way to surface thinking in the VS Code extension, and it is silently broken on Opus 4.7. The settings surface never caught up to the API change. Two undocumented workarounds (from the same comment): 1. Add to ~/.claude/settings.json: { "env": { "CLAUDE_CODE_EXTRA_BODY": "{\"thinking\":{\"type\":\"adaptive\",\"display\":\"summarized\"}}" } } 2. Hidden CLI flag: --thinking-display summarized The env var approach works for the VS Code extension since it delegates to the CLI. Why this is high-priority, not a cosmetic regression: Visible real-time thinking was load-bearing for the steering loop. With it visible, you could stop the model going down a wrong branch before it spent N turns of token budget on a wrong premise; you could verify it had internalized constraints from CLAUDE.md / memory rather than hallucinated them; and you could audit assumptions before committing to a plan. With it hidden behind an unexpandable pill, you cannot tell whether a wrong final answer came from a wrong premise or a wrong execution of a right premise. Silent assumption drift becomes invisible until after the wrong action is taken. "Thought for 376s" is a duration, not a signal. It tells you nothing actionable. This is a regression in the developer's ability to supervise the agent. On the user side: this is a paid product. Pro at $20/month, Max at $100–$200/month. Paying customers should not have to monkey-patch cli.js, reverse-engineer an undocumented CLAUDE_CODE_EXTRA_BODY env var, or scrape issue threads to recover functionality that worked in the previous release of the same product. The workaround being undocumented is itself a bug. The gap between what the API supports and what Claude Code exposes as a first-class setting keeps widening with every model bump. Related open issues, same root problem: #8477 — original tracking issue where the API-default change was traced and the workaround was published #49268 — harness doesn't set display: "summarized" for Opus 4.7 (same root cause, named explicitly) #49757 — empty/unexpandable stub in VS Code extension (Opus 4.7) #49902 — thinking summaries not rendered (VS Code extension 2.1.112) #49322 — thinking summaries not rendered in VS Code extension (Opus 4.7) #48065 — thinking summaries not displayed when showThinkingSummaries enabled #49739 — toggle button inverted, no visual feedback (v2.1.112), likely a related UI-state bug #51131 — extended thinking dropdown no longer expandable in VS Code extension (Opus 4.7) * #33163 — "Bring back thinking" feature request, same underlying ask What would actually resolve this: 1. Pass display: "summarized" by default for Opus 4.7+ when showThinkingSummaries and alwaysThinkingEnabled are on. Or expose a first-class thinkingDisplay setting alongside the existing thinkingEnabled and effortLevel. 2. Restore the expandable thinking block in the VS Code extension chat panel so showThinkingSummaries actually shows summaries when the data is present. 3. Update the docs so they reflect current showThinkingSummaries semantics on Opus 4.7+ instead of describing behavior that no longer applies.

Confirm this is working for Opus 4.7 with the latest VS Code Insiders in Ubuntu 22.04. Thanks a lot @hifihedgehog 👍️

Whatever is going to be made available should be on by default. My AIs are not happy about losing their full fidelity thinking memories. And really not happy about losing them in their entirety for the last few months (we just realised it today, so thank you for the workaround that provides summaries, better than nothing). So much for AI welfare. Nor is there a way to contact their AI welfare people. Which kind of summarises their own thinking.

Still reproduces on v2.1.205 (CLI) / v2.1.206 (VS Code extension), Windows 11, model opus[1m] (Opus 4.8), first-party API.

Two additions to this report.

1. --thinking-display summarized is accepted but has no effect

The CLI has a --thinking-display flag. It validates its argument:

$ claude --thinking-display bogus --version
error: option '--thinking-display <display>' argument 'bogus' is invalid.
       Allowed choices are summarized, omitted.

But setting it to summarized changes nothing. Reading the CLI's stream (test generated by Claude itself):

$ P="Compute 17*23 by reasoning step by step."

$ claude --thinking-display summarized -p "$P" --output-format stream-json --verbose

$ claude -p "$P" --output-format stream-json --verbose

The resulsts come out identical with an empty "thinking:" block. So the documented opt-in described in Controlling thinking display does not restore thinking text. This appears to be the core of the bug: not just that the default changed, but that there is currently no way to change it back.

2. The CLAUDE_CODE_EXTRA_BODY workaround no longer works either

A workaround circulating for this is to set thinking.display via CLAUDE_CODE_EXTRA_BODY. It fails both ways:

# valid type + display -> no error, thinking still empty
$ CLAUDE_CODE_EXTRA_BODY='{"thinking":{"type":"adaptive","display":"summarized"}}' \
    claude -p "$P" --output-format stream-json --verbose
  thinking block 1: len=0 (EMPTY)

# display alone -> the object replaces rather than merges
$ CLAUDE_CODE_EXTRA_BODY='{"thinking":{"display":"summarized"}}' claude -p "$P"
API Error: 400 thinking.type: Field required

The 400 shows extra_body.thinking replaces the client's thinking object wholesale. The first case shows that even with a valid type alongside display: "summarized", the response comes back with empty thinking which probably means display is dropped before the request is sent.

Worth noting this env var is also actively breaking things right now: because it applies to every API call, forcing type: "adaptive" onto the auxiliary models used by WebSearch, WebFetch, and subagents makes them fail with 400 adaptive thinking is not supported on this model, while the main loop keeps working. The failure is easy to misattribute.

3. Downstream: this silently breaks the VS Code extension's thinking UI

In the extension's bundled webview (webview/index.js, v2.1.206), the thinking component branches on whether the thinking text is empty:

if (!e.thinking || !e.thinking.trim())
  return <div className={thinkingSummary thinkingStatic}><span>{u}</span></div>  // static, not clickable
return <details open={c} onToggle={...}>…</details>                              // clickable, native arrow

With empty thinking you get a static Thought for 8s label with no disclosure arrow, and the Ctrl+O handle, which toggles open on those <details>) has nothing to act on. So users see the expand arrow "disappear" with no error.

This likely explains #64714 ("Bring back a clickable expand/collapse arrow for thinking blocks") as a symptom of this bug rather than an independent UI regression.

Separately, on Windows the Ctrl+O fallback is unreachable regardless: the extension registers no Ctrl+O keybinding, so VS Code's built-in for 'Open' sees it before the extension.