Thinking summaries missing on Opus 4.7 — harness doesn't set display: "summarized"

[yusufmo1]

Switched to Opus 4.7 on v2.1.111 and noticed thinking summaries stopped showing up. Took a bit to track down — writing it up in case it's useful.

The extended-thinking API docs note that Opus 4.7 changed the default for the display parameter to "omitted" (Opus 4.6 and earlier defaulted to "summarized"). The reason given is faster time-to-first-token on streaming responses.

The result is the API returns thinking blocks with empty thinking fields by default, so the UI has nothing to render. Setting "showThinkingSummaries": true in settings.json doesn't help — that controls rendering of what the API sends back, not what the API decides to send.

Repro

1. Run v2.1.111 with "showThinkingSummaries": true set
2. /model claude-opus-4-7
3. Ask something that triggers extended thinking
4. No summaries appear in the UI

Switching to claude-opus-4-6 or claude-sonnet-4-6 brings them back since those still default to "summarized".

Suggested fix
When the selected model defaults to display: "omitted" (currently Opus 4.7 and Mythos Preview per the docs) and the user has showThinkingSummaries enabled, the harness should pass display: "summarized" explicitly in the API request.

Environment

• Claude Code 2.1.111
• Model: claude-opus-4-7 (1M context variant)
• macOS 15.3 (Darwin 25.3.0)

[yusufmo1]

Dug into the v2.1.111 binary to confirm what's actually broken. The bug: the showThinkingSummaries: true setting and the API's thinking.display parameter are two completely unrelated systems in the harness — there is no code path that wires one to the other. So enabling the setting can't make summaries come back; whether you get them depends entirely on the model's API default, which Opus 4.7 flipped to "omitted".

here's the request-construction code:

const bH = V_ ? q.display ?? undefined : undefined;
const QH = { type: "adaptive", display: bH };  // sent as the thinking parameter

bH is sourced only from q.display, an internal field on the thinking config object. Nothing reads showThinkingSummaries and assigns it to q.display. So bH is always undefined, the display field drops out of the request, and Opus 4.7 returns empty thinking blocks.

What showThinkingSummaries actually controls — straight from the embedded schema string:

showThinkingSummaries: "Show thinking summaries in the transcript view (ctrl+o). Default: false."

It governs (a) the Ctrl+O transcript-view renderer and (b) whether the redact-thinking-2026-02-12 beta header is sent. Neither has any effect on the API's display parameter. The naming overlap is misleading — a user reasonably assumes the setting controls whether summaries are requested, but it doesn't.

There's a related model-version gate nearby:

const z_ = env.CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING && (model.includes("opus-4-6") || model.includes("sonnet-4-6"));

That allowlist was never extended to 4.7 — same regression pattern: the request-construction code still treats 4.6 as the newest model.

Suggested minimal fix: when showThinkingSummaries === true, set q.display = "summarized" so it flows into bH and onto the request. Or, simpler and more correct: send display: "summarized" unconditionally for any model where the API defaults to "omitted" (currently Opus 4.7 and Mythos Preview), with an explicit opt-out for users who want the latency benefit of "omitted". The 4.6/sonnet-4.6 model checks should also be extended to cover 4.7+.

[mjesuele]

Confirmed the diagnosis with a binary patch on v2.1.112 (Linux x86-64).

The request-construction code has:

CH=h$?q.display??void 0:void 0

q.display is never populated from the showThinkingSummaries setting, so CH is always undefined and Opus 4.7's default ("omitted") wins.

Fix: q.display??void 0 and "summarized" are both 17 bytes. Replacing in-place with sed:

cp /path/to/2.1.112 /path/to/2.1.112.bak
sed -i 's/q\.display??void 0/"summarized"     /g' /path/to/2.1.112

Two occurrences patched (offsets 119213276 and 232078516 in my build). Thinking summaries now display correctly on Opus 4.7 with showThinkingSummaries: true. Survives until next claude update.

[Nitjsefnie]

Verified --thinking-display summarized restores populated thinking blocks on Opus 4.7 end-to-end (Claude Code 2.1.112, first-party / Max subscription).

Settings alone don't work. Before: ~/.claude/settings.json already had both showThinkingSummaries: true AND thinkingDisplay: "summarized". Persisted jsonl still showed {"type":"thinking","thinking":"","signature":"..."} on every Opus 4.7 turn. A local sweep across all my session jsonls was clean: 2.1.97–2.1.110 with opus-4-6 → 3,399/3,399 populated; 2.1.111 with opus-4-7 → 134/134 empty; 2.1.111 with synthetic helper model → populated. So showThinkingSummaries: true is doing its job at the beta-header level (no redact-thinking-2026-02-12 sent), but matches @yusufmo1's diagnosis that it doesn't feed into q.display — and the 4.7 server default "omitted" wins.

CLI flag works. Same binary, same settings — just launched a new claude session with claude --thinking-display summarized. The resulting jsonl writes populated thinking blocks with valid signatures:

• L8 block[0]: 202 chars, populated, signature present
• L23 block[0]: 87 chars, populated, signature present

First-party Max, no binary patch, no CLAUDE_CODE_EXTRA_BODY — just the flag.

Persistence for interactive shells:

alias claude='claude --thinking-display summarized'

Caveat: only affects interactive-shell invocations of claude. Non-interactive callers (cron, systemd, scripts with #!/bin/sh) won't pick up the alias — a wrapper earlier on $PATH than the real binary would cover those.

[narner90]

Verified --thinking-display summarized restores populated thinking blocks on Opus 4.7 end-to-end (Claude Code 2.1.112, first-party / Max subscription).

Settings alone don't work. Before: ~/.claude/settings.json already had both showThinkingSummaries: true AND thinkingDisplay: "summarized". Persisted jsonl still showed {"type":"thinking","thinking":"","signature":"..."} on every Opus 4.7 turn. A local sweep across all my session jsonls was clean: 2.1.97–2.1.110 with opus-4-6 → 3,399/3,399 populated; 2.1.111 with opus-4-7 → 134/134 empty; 2.1.111 with synthetic helper model → populated. So showThinkingSummaries: true is doing its job at the beta-header level (no redact-thinking-2026-02-12 sent), but matches @yusufmo1's diagnosis that it doesn't feed into q.display — and the 4.7 server default "omitted" wins.

CLI flag works. Same binary, same settings — just launched a new claude session with claude --thinking-display summarized. The resulting jsonl writes populated thinking blocks with valid signatures:

* L8 block[0]: 202 chars, populated, signature present

* L23 block[0]: 87 chars, populated, signature present

First-party Max, no binary patch, no CLAUDE_CODE_EXTRA_BODY — just the flag.

Persistence for interactive shells:

alias claude='claude --thinking-display summarized'

Caveat: only affects interactive-shell invocations of claude. Non-interactive callers (cron, systemd, scripts with #!/bin/sh) won't pick up the alias — a wrapper earlier on $PATH than the real binary would cover those.

That fix does not seem to be working for me on linux, version 2.1.110

[alkautsarf]

Confirming this still happens on 2.1.112 (one version newer than reporter).

Dug into the binary and there's a hidden CLI flag that already does the right thing:

--thinking-display <display>  choices: summarized, omitted   .hideHelp()

Verified end-to-end: launching with claude --thinking-display summarized on Opus 4.7 restores populated thinking blocks. So the API plumbing is wired — the gap is that:

1. The flag is .hideHelp(), so claude --help doesn't show it (hard to discover)
2. There's no equivalent settings.json key, only alwaysThinkingEnabled (boolean enable/disable, doesn't control display)
3. The CLI builds {type:"adaptive"} without a display field by default, so the request inherits Opus 4.7's new display:"omitted" default

Suggested fix (small surface):

• Un-hide --thinking-display from --help
• Add a thinkingDisplay: "summarized" | "omitted" settings.json key that maps to the same flag, so users on 4.7 can persist the preference without wrapping claude in a script
• Bonus: when alwaysThinkingEnabled: true is set with no explicit thinkingDisplay, default display to "summarized" (matches user intent — they enabled thinking because they want to see it)

Workaround for anyone reading this: add --thinking-display summarized to your launcher wrapper.

[Hammaarn]

Adding a workflow-impact voice to this thread — the existing comments cover diagnosis and workarounds well, but the severity case hasn't been made from a power-user angle.

My orchestration system is architected around visible reasoning: agent dispatch targeting, lens activation decisions, verification-before-completion, panel reviews. I don't use reasoning visibility as a UX nicety — it's the primary surface I use to catch misinterpretations before code is written, sanity-check dispatches before approving, and debug decisions in flight. On 4.7 with the current default, that entire layer is opaque. The functional downgrade is substantial.

Separately, the naming collision is genuinely misleading: showThinkingSummaries: true sounds like it controls whether summaries are requested. It doesn't, and the gap between "setting enabled" and "no summaries appearing" reads as a bug long before a user thinks to check the API default.

Proposed priority: promoting --thinking-display out of .hideHelp() and adding a thinkingDisplay settings.json key is a few lines of code for substantial workflow recovery. Developer-tool audiences are not the same audience as consumer-chat — the default for Claude Code probably shouldn't inherit the latency-optimized API default.

Also upvoting the suggestion that alwaysThinkingEnabled: true with no explicit thinkingDisplay should default to "summarized" — matches user intent.

[geraertsf]

Another +1 on 2.1.112 macOS with claude --thinking-display summarized aliased. Posting the raw jsonl diff since prior comments described it but didn't show it side-by-side from the same setup:

Before the alias, same settings.json:

{
  "type": "thinking",
  "thinking": "",
  "signature": "<redacted>"
}

After the alias, next session, nothing else changed:

{
  "type": "thinking",
  "thinking": " The user is asking in French, so I'll respond in French without any special formatting. To find the trailing zeros in 100!, I need to count how many times 10 divides into it, [...]",
  "signature": "<redacted>"
}

Signature is issued in both cases — only the thinking text differs, exactly matching @yusufmo1's diagnosis.