[Feature Request] Expose thinking-block display controls as first-class config

Bug Description
Please expose thinking-block display controls as first-class config (lost in 2.1.113 native-binary switch)

Writing as a daily Claude Code user who just lost a core part of my workflow and wants to make the case for getting it back properly — this time as official config,
not a sed hack.

## Why I care about this specifically

I use Opus 4.7 for complex engineering work and follow along with the model's reasoning in real time. Seeing the thinking stream lets me:

• Catch false leads early and redirect before the model commits to a bad approach.
• Genuinely learn from how the model frames problems — it meaningfully improves my own prompting.
• Build trust — it's the difference between "pair-programming with a collaborator I can reason with" and "waiting on a black box."

For any agentic workflow where a human is in the loop, the ability to see reasoning IS the supervision. This is the UX difference between Claude Code feeling like a
teammate vs. a slot machine.

## What changed in 2.1.113

For months I've been running a community-pattern sed patcher patch-thinking-blocks.sh against @anthropic-ai/claude-code/cli.js that did three things:

1. Removed the case"thinking":{if(!D&&!$)return null; early return so thinking renders in the live view.
2. Forced isTranscriptMode: true on the thinking component so content actually rendered.
3. Changed the API request default for thinking.display from undefined to "summarized" — critical for Opus 4.7, which returns empty thinking blocks otherwise.

With 2.1.113's move to a Bun-compiled native Mach-O binary at bin/claude.exe, the JS source is embedded as readable bytes but the patcher's length-changing edits
break the binary, and length-preserving regex on a 204MB Mach-O is not something I'm excited to maintain.

## The config-surface gap

I traced through the 2.1.113 binary strings. What I found:

• Settings schema is thinking: y.string() at the root — nested {type, display} forms get silently dropped.
• showThinkingSummaries per its own schema description only affects the ctrl+o transcript view, not live rendering.
• The adaptive API config is built as gH = {type:"adaptive", display: NH} where NH = G_ ? q.display : void 0 — and q.display is never populated from user

config on the adaptive path.

So there is no exposed setting, env var, or CLI flag in 2.1.113 that forces thinking.display: "summarized" on the API request for adaptive-mode models. For Opus
4.7 that means empty thinking blocks, full stop.

## What I'm asking for

Three concrete things, in order of impact:

1. thinkingDisplay as a first-class flat settings key wired through on the adaptive path. One-line change: if I set "thinkingDisplay": "summarized" in

~/.claude/settings.json, Opus 4.7 should receive thinking.display: "summarized" in the request body.

1. A dedicated toggle to auto-expand thinking in the live view without full verbose mode (verbose also expands tool-call output, which is too noisy to follow along

with). Something like "expandThinkingInline": true. The existing render gate is effectively if (!isTranscriptMode && !verbose) return null — adding a third
OR-clause is a one-line change.

1. An env var escape hatch (e.g. CLAUDE_CODE_THINKING_DISPLAY=summarized) for folks who don't want to persist it in user settings.

The fact that a patch community formed around these toggles is the strongest signal they're worth shipping officially. Formalizing them is a few hours of work and it
keeps your power users on current versions instead of pushed toward downgrade-and-pin as the only viable workflow.

Love the product. Please give us our thinking back.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.113
• Feedback ID: 6afa2280-5655-4ae3-8eef-c6ecc5b17163