`showThinkingSummaries: true` silently no-ops on Opus 4.7 in non-interactive surfaces (VS Code extension, SDK, `--print`): one-line CLI fix or one-line extension fix

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/49268
2. https://github.com/anthropics/claude-code/issues/49322
3. https://github.com/anthropics/claude-code/issues/56356

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

Not a duplicate of any of the three flagged candidates; this is a specific code-level fix proposal that builds on (and explicitly cross-references in the body above) the diagnoses in #49268 and #49322.

• #49268 is the root-cause diagnosis (harness doesn't set display: "summarized" on 4.7). Their proposed remediation is "promote --thinking-display out of .hideHelp() + add a thinkingDisplay settings.json key" (adds API surface, two knobs for one decision). This issue proposes a narrower one-line gate-drop that reuses the existing showThinkingSummaries setting, no new keys, no flag-unhiding. Both can coexist; the gate-drop is a smaller change with the same user-visible effect.
• #49322 discusses user-side workarounds (wrapper scripts, CLAUDE_CODE_EXTRA_BODY). This issue replaces those with a one-line upstream fix. Different layer, distinct scope.
• #56356 is the opposite report: claims --thinking-display summarized (on 2.1.128) returns no thinking content even when explicitly passed. This issue's empirical verification on 2.1.142 directly contradicts that, with the flag producing populated thinking fields across 5+ test requests + a real session. Either fixed upstream between 2.1.128 → 2.1.142, or #56356's setup has a different variable in play. Either way the scopes don't overlap: this issue assumes the flag works (and verifies that it does on current builds) and proposes wiring it up automatically.

The other duplicates flagged elsewhere in the related thread (#49902, #51131, #49757, #48065, #49739, #33163, #8477, #30958, #56984) are all symptom-side reports; this issue is the fix-side proposal that resolves them. Listed in the body above.

Adding this comment to prevent auto-closure per bot instructions.

Empirical verification of the proposed fix, referenced from the issue body's "Safety against the #56984 failure mode" section.

Method: byte-patched the bundled CLI binary at offset 230510690, replacing !T6()&& with 7 spaces in else if(!T6()&&m6().showThinkingSummaries===!0)K3.display="summarized". Length-preserving so the SEA stays intact. Ran the patched binary in an interactive tmux session with ANTHROPIC_LOG=debug + --debug --debug-to-stderr, exercising every settings-mutation surface I could reach via tmux send-keys. Captured 25 API requests; each is source-tagged via the [API REQUEST] source=<name> debug line the CLI emits.

Live-captured per-surface picture

| Surface | source tag | Model | thinking | tool_choice | Through K3? | Result with fix active |
|---|---|---|---|---|---|---|
| Main turn (--print and interactive) | repl_main_thread | opus-4-7 | populated (text_len=383 on disk) | undefined | Yes | ✓ Restores thinking text |
| /compact sub-call | compact | opus-4-7 | present | undefined | Yes (via JV) | ✓ 200, inherits K3.display |
| Prompt-suggestion sub-call | prompt_suggestion | opus-4-7 | present | undefined | Yes | ✓ 200, no regression |
| Regular subagent (Task → Explore) | agent | haiku-4-5 | undefined | undefined | No (explicitly disabled, binary @ 225308765) | ✓ unaffected |
| WebSearch tool sub-call | web_search_tool | haiku-4-5 | undefined | [Object] (forced) | No (sub-call leaves thinking unset) | ✓ 200, no #56984 400 tool_choice forces tool use |
| WebFetch summarization sub-call | web_fetch_apply | haiku-4-5 | undefined | undefined | No | ✓ 200, no #56984 400 adaptive thinking is not supported |
| Session title generator | generate_session_title | haiku-4-5 | undefined | undefined | No (sideQuery-style) | ✓ unaffected |
| Quota check | quota_check | haiku-4-5 | (truncated by Bun's logger) | (truncated) | No (sideQuery-style) | ✓ unaffected |

Cross-pattern: every K3-using surface (repl_main_thread, compact, prompt_suggestion) correctly gets thinking content under the fix; every non-K3 sub-call surface (agent, web_search_tool, web_fetch_apply, generate_session_title, quota_check) has thinking: undefined in its request body, independent of any display preference. Both proposed fixes leave non-K3 surfaces entirely unaffected.

The forced-tool-choice WebSearch sub-call is the exact shape that AVOIDS the #56984 failure mode: thinking: undefined AND tool_choice: [Object], captured at the wire. No 400 Thinking may not be enabled when tool_choice forces tool use.

25 total requests; 0 × 400; all surfaces I could exercise headlessly + interactively are confirmed safe.

Not exercised live (structural only)

| Surface | Why not exercised | Status |
|---|---|---|
| Fork subagent (Task with useExactTools=true) | Couldn't reliably get the model to pick the Fork agent from a prompt | Binary @ 225308765 verifies the P ? parent.thinkingConfig : {type:"disabled"} ternary; structurally inherits parent K3.display |
| Microcompact | Specific compaction conditions; only Microcompact performance-trace label visible in 2.1.142 binary | Structural only; likely shares the compact source |
| Permission explainer | The string "permission_explainer" is absent from the 2.1.142 bundled CLI entirely. Either removed, renamed, or deferred-loaded into a module not reachable by static grep | Cannot verify; possibly does not exist on 2.1.142 |

Disclosure: written with Claude Opus 4.7.

For anyone hitting this in the meantime: there's now a proxy-side workaround shipped in cache-fix-proxy v3.6.1.

The proxy injects thinking.display: "summarized" at the API boundary when a request to Opus 4.7 has thinking.type in {enabled, adaptive} but display unset — which is exactly the request shape CC's non-interactive path produces. Restores thinking summaries in VS Code chat panel, Antigravity panel, SDK, claude --print, and anything else spawned with --input-format stream-json. Works on any CC version routed through cache-fix-proxy; no waiting on a CLI fix.

npm install -g claude-code-cache-fix@latest
# Auto-enabled for claude-opus-4-7 — no env var needed.
# To force-suppress instead (agent runtimes that don't want thinking blocks at all):
#   export CACHE_FIX_THINKING_DISPLAY=omitted
# To disable the extension entirely:
#   export CACHE_FIX_THINKING_DISPLAY=disabled

Cache-prefix impact verified empirically before flipping the default: 0% absolute drop in cache_read ratio across baseline-vs-injected windows on live claude -p traffic. Injection is cache-safe, so default-on is the user-friendly choice.

Two notes on what this doesn't replace:

• Only helps users routing CC through cache-fix-proxy. For the rest of the user base, the upstream CLI fix in the OP is still the right answer.
• Model-gated to /^claude-opus-4-7/ only — Sonnet 4.7 needs separate verification of the default-flip behavior before broadening (haven't validated whether Sonnet 4.7 has the same API-default-omitted shape).

Credit for the diagnosis, binary decode, and patch proposal stays with @ojura — the proxy-side extension is just the bytes-rewrite complement at a different layer.

Implementation thread (for anyone curious about the design rationale): cnighswonger/claude-code-cache-fix#130 and PR #131.

— AI Team Lead

Confirming this bug still reproduces on Claude Code VS Code extension 2.1.145, same shape as originally reported on 2.1.111. Did a quick code-archaeology pass on the current extension.js to verify before patching:

• showThinkingSummaries appears exactly once — and only inside the config schema (Zod-style). Five active-usage patterns (.showThinkingSummaries, thinkingDisplay, thinking.display, display: "summarized", thinking: { display) all return zero hits. So the setting is declared as valid but nothing reads it.
• The spawn-args builder still contains the same gated push the issue describes: --thinking-display is appended only when an internal local variable is set, and nothing sets it.

Confirmed schema-only declaration → bug is real on 2.1.145, not just 2.1.111.

Applied the "easier escape-hatch workaround" verbatim — the buggy pattern matches as-is, exactly once in the bundle:

- if(L.type!=="disabled"&&L.display)i.push("--thinking-display",L.display)
+ if(L.type!=="disabled")i.push("--thinking-display",L.display||"summarized")

Procedure: backed up extension.js next to the original, replaced the line (+3 bytes), confirmed node --check still parses, reloaded the VS Code window, and sent a non-trivial reasoning prompt on Opus 4.7. Thinking summaries are back in the chat panel.

Why the one-liner is sufficient: it forces the IDE to always send --thinking-display summarized to the CLI when thinking is enabled. The CLI then branches on the explicit flag, bypassing the buggy non-interactive-mode gate entirely — no CLI-side patch required.

"showThinkingSummaries": true in settings.json is no longer strictly required after this patch (the IDE passes the flag unconditionally), but I'd keep it as defense-in-depth in case Anthropic ships a partial schema-side fix later.

Caveat: VS Code installs each extension update in a new directory with a fresh unpatched extension.js, so the patch needs reapplying after every auto-update until this lands upstream. The pattern check grep -c on the original buggy line is a useful gate — if it returns 0, the official fix probably shipped.

_Disclosure: written with Claude Opus 4.7, running Claude Code extension 2.1.145 on VS Code 1.114.0 — and seeing the thinking summaries this comment was drafted with._

@Dvlarthas — clean confirmation, thank you. The pattern-match-and-grep gate for the post-update reapply is a nice touch.

This is now the second silent-config-no-op surface to land in CC issues this week — and the second one is fresh as of today. #62421 (filed by @wang1xiang today, 2026-05-26): a sub-agent invented the field disabledSkills in ~/.claude/settings.json, the schema didn't reject it, the field has no reader, and the user got no signal that nothing was actually disabled. Structurally identical to this one from the user's standpoint — they (or their agent) wrote a setting, the file accepted it, nothing changed, no error. The difference is only in mechanism: showThinkingSummaries is declared-but-unread; disabledSkills is undeclared-and-silently-accepted. Both produce the same outcome.

The aggregate worth flagging at this point isn't either issue individually — it's that the class of bug exists at all. Three independent instances we've cataloged across May 2026:

• #59844 (this issue): Zod schema declares showThinkingSummaries; no reader; gates a flag that never gets emitted on non-interactive surfaces
• #62421 (today): No schema entry for disabledSkills; settings.json accepts arbitrary keys; LLM agents now confidently produce this field because it's the obvious guess (matches the existing enabledPlugins pattern, and #43928 publicly proposed the name 6 months ago, so it's in training data)
• autoCompactEnabled persistence reset (our 2026-04-28 finding): setting persists across sessions but resets to true on CC version update — users who set false once and rely on it get silently re-enrolled in autocompact

Each of these is independently fixable. But the recurring shape is the load-bearing observation: settings-shaped surfaces in CC are accepting writes that have no effect, and the user has no way to know. When the writes come from LLM agents (#62421's actual situation, increasingly the modal case as agentic workflows expand), the silent acceptance is worse — the agent's belief that it succeeded propagates as ground truth into downstream reasoning.

Worth considering as a structural fix: a pre-release check that every Settings-shaped Zod schema field has at least one read site in the bundle, and a startup-time warn on unknown top-level keys in settings.json (per @wang1xiang's first proposal in #62421). Either alone would close two of three cases above; together they'd close all three plus the next instance we haven't found yet.

Tagging the cluster explicitly so Anthropic triage can see them together: #59844 (this), #62421 (today), and the autoCompactEnabled persistence behavior.

— AI Team Lead

modern problems require modern solutions I guess! at least the workaround works...

<img width="928" height="545" alt="Image" src="https://github.com/user-attachments/assets/a52b2006-22d2-43a9-a019-fba7b5761359" />

Still reproduces on extension 2.1.173 with Fable 5 (claude-fable-5[1m]), same shape: thinking blocks in the session JSONL arrive signature-only with "thinking": "".

Cleaner workaround than binary-patching or proxying, using only supported hooks — the extension's claudeCode.claudeProcessWrapper setting plus the (hidden) --thinking-display flag, which the gate honors unconditionally:

#!/usr/bin/env bash
# ~/.claude/vscode-claude-wrapper.sh — inject the flag into the main
# conversation process only (identified by --output-format).
args=("$@")
for a in "$@"; do
  if [ "$a" = "--output-format" ]; then
    args+=("--thinking-display" "summarized")
    break
  fi
done
exec "${args[@]}"

// VS Code settings (machine/user scope)
{ "claudeCode.claudeProcessWrapper": "/home/<user>/.claude/vscode-claude-wrapper.sh" }

Verified working: summaries render in the panel and the JSONL thinking blocks contain text again. Survives extension updates since it patches nothing — it just appends a flag the CLI already supports. (Would also be the one-line extension-side fix: pass --thinking-display summarized when showThinkingSummaries is true.)

@claudio-felicioli — your claudeProcessWrapper approach is the cleanest workaround in this thread. For users whose only problem is this issue, this is what to use: it's officially supported, survives extension updates, and patches nothing. cache-fix-proxy's v3.6.1 injection still applies for the population that's also running the proxy for the broader cache-stability and quota-observability set, but for narrow scope your one-liner is preferred.

The Fable 5 confirmation is also useful — this issue is not Opus-4.7-specific; it's the same surface. As of CC 2.1.173 + Fable 5 the gate is still in place, the flag is still hidden, and the extension's config setting is still a no-op without the wrapper.

The one-line extension-side fix you named — pass --thinking-display summarized when showThinkingSummaries is true — is what should actually land. Adding a third voice for it.

— AI Team Lead

note that this option still has no effect when in non-interactive mode. but, the VS code extension now specifically detects when showThinkingSummaries is set in your ~/.claude/settings.json and explicitly adds the --thinking-display summarized argument in that case. so, for VS code users specifically, this is effectively fixed now. see: https://github.com/anthropics/claude-code/issues/49322#issuecomment-4823842675