claude-code - 💡(How to fix) Fix `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

Summary

~/.claude/settings.json → "showThinkingSummaries": true is the documented, official way to surface thinking summaries in the VS Code / Antigravity chat panel. On claude-opus-4-7[1m] and presumably any 4.7+ model, the setting silently no-ops: the API returns thinking content blocks with empty thinking field + multi-KB signature only, and the webview renders the static <div class="thinkingStatic">Thinking</div> stub because its thinking.length > 0 branch can't fire.

Closes the symptom side of: #49902, #49322, #49268, #51131, #49757, #48065, #49739, #33163, #8477, #30958. Cross-references the workaround failure modes: #56984.

Root cause

The bundled CLI (v2.1.142, native-binary/claude offset 230510599) builds the thinking config like this:

if (K3.type !== "disabled") {
  if (z.thinkingDisplay === "summarized" || z.thinkingDisplay === "omitted")
    K3.display = z.thinkingDisplay;        // branch A: explicit CLI flag wins
  else if (!T6() && m6().showThinkingSummaries === !0)
    K3.display = "summarized";              // branch B: interactive + setting
}

T6() is getIsNonInteractiveSession(). Branch B requires interactive mode. The IDE spawns the CLI as --print --input-format stream-json --output-format stream-json, which makes T6() === true, so branch B never fires for chat-panel subprocesses. Setting showThinkingSummaries: true in settings.json is honored at the BETA-HEADER gate (redact-thinking-2026-02-12 correctly not added), but never propagates to K3.display. Anthropic's own Opus 4.7 migration guide documents that the API default for thinking.display flipped from "summarized" to "omitted" on 4.7, so without explicit display: "summarized", the API returns nothing user-visible.

The same surface ships across SDK / --print / VS Code / Antigravity chat panel: all non-interactive from the CLI's perspective.

Why the gate exists, and why dropping it is safe

The !getIsNonInteractiveSession() pattern is reused from the REDACT_THINKING_BETA_HEADER gate in src/utils/betas.ts (whose in-source comment explains: SDK/print-mode callers iterate over thinking content programmatically, so they shouldn't get redacted blocks). That justification applies to the beta-header gate. It doesn't apply to the display-assignment gate: with display: "summarized", SDK callers still get content (summary form) instead of nothing. The new gate appears to have been added defensively by pattern-copying, but the behavioral consequence for 4.7+ is that the entire non-interactive population loses thinking content visibility.

The CLI binary only checks display === "summarized" and === "omitted" (no "full" value exists), so:

• Pre-4.7 models: API default already returns text in thinking. Setting display: "summarized" returns summary text. Webview reads thinking regardless of what produced it. SDK callers who specifically want non-summarized behavior keep the --thinking-display CLI flag for explicit opt-out.
• 4.7+ models: gate change is what restores any visible thinking content at all.

No model version regresses; 4.7+ improves.

Fix option A (preferred, one-line CLI change)

Drop the !T6() gate from the display assignment in the bundled CLI:

- else if (!T6() && m6().showThinkingSummaries === !0)
+ else if (m6().showThinkingSummaries === !0)
    K3.display = "summarized";

Single setting, single knob, works in every surface. No extension-side changes needed.

Fix option B (alternative, one-line extension change)

If the CLI gate must stay for reasons not visible from the leaked source, the equivalent fix at the extension layer is:

In extension.js's SDK-side spawn-args builder:

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

Drops the && U.display guard (which was suppressing the flag because the chat-panel caller never sets U.display) and adds || "summarized" as the fallback. Every IDE-spawned subprocess then gets --thinking-display summarized in argv, branch A in the CLI fires regardless of interactive state, and the request includes thinking.display: "summarized".

Why both options are safer than the CLAUDE_CODE_EXTRA_BODY workaround documented in #56984

CLAUDE_CODE_EXTRA_BODY breaks WebSearch (400 Thinking may not be enabled when tool_choice forces tool use) and WebFetch (400 adaptive thinking is not supported on this model) because it force-injects {"type": "adaptive", ...} into every API request, bypassing the CLI's per-request logic that would otherwise disable thinking for forced-tool-use calls and incompatible-model sub-calls.

Both proposed fixes set display only, never type. The CLI's per-request gate is q.type !== "disabled", so when WebSearch / WebFetch / auto-mode classifier paths build their own per-request thinking config with type disabled (or with a thinking-incompatible model), the entire thinking field is dropped regardless of q.display.

Empirical verification (option B applied locally on v2.1.142)

• Spawn args: ps -ef | grep claude shows --thinking-display summarized on every IDE-spawned chat-panel subprocess.
• On-disk JSONL: post-fix chat-panel turns produce thinking blocks with text_len > 0, sampled at 209, 511, 612, 2117, 115 chars in the verification session. Pre-fix turns in the same session are all text_len = 0.
• WebSearch regression check: claude --print --thinking-display summarized --allowed-tools WebSearch "search ..." produced 5+ API requests, all 200 OK, no 400. The forced-tool-use path is unaffected.
• Helper subcommands (--version, doctor, mcp list, plugin list): all accept --thinking-display summarized in argv without crashing on 2.1.142. The Gotcha2 from #49322 (wrapper-script breakage) doesn't reproduce on this version. Suggests the @shawnz /plugins failure with the unconditional wrapper was version-specific to older 2.1.11x builds.

Tradeoff vs other proposals in the thread

• Wrapper-script approach (claudeProcessWrapper, per #49322 comments): user-side glue, fragile (Gotcha2, /plugins breakage in @shawnz's report), requires per-OS wrapper code, no version stability.
• CLAUDE_CODE_EXTRA_BODY env var (per #49322 and #56984): breaks WebSearch / WebFetch.
• Promote --thinking-display out of .hideHelp() + add thinkingDisplay settings.json key (per #49268): adds API surface, two knobs for one decision.
• This proposal: one-line CLI fix (or one-line extension fix), no new API surface, single knob is the existing documented setting.

Disclosure

Written with Claude Opus 4.7, which currently has its own thinking summaries hidden by this exact gate.