[FEATURE] Structured thinking/reasoning log file for real-time debugging

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude uses extended thinking, the reasoning is visible while streaming but collapses in the TUI immediately after. There's no way to retrieve it as Ctrl-O briefly re-shows the last block but auto-dismisses while Ctrl-E does nothing insofar as displaying the thinking again. For complex reasoning chains or running hybrid local/cloud setups, losing the thinking output is a real insight deficit of high value that was formerly, albeit ctrl-shift-c & ctrl-v into kate as fast as possible before you miss it, a feature and valuable data point. Current workarounds:

(DEBUG=true, ANTHROPIC_LOG=debug) exposes raw HTTP noise, or SDK internals, neither gives a clean, readable thinking stream.

Proposed Solution

A flag or env var (e.g. CLAUDE_THINKING_LOG=/tmp/cc-thinking.log) that appends each thinking block to a file as it streams:

'tail -f /tmp/cc-thinking.log'

Alike Qwen Code's --openai-logging --openai-logging-dir <dir>, whch writes structured API logs persession. A thinking-specific equivalent for CC would cover the gap with low impl. cost; thinking blocks are already structured internally and just need a write path.

Alternative Solutions

Persistent Ctrl-O / Ctrl-E view would also solve it. Given those who find it useful enough to be editing settings.json, exporting env vars, and enabling Tengu fallback--showing the energy/need vs work is there--we just need a destination to complete the flow.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

During a refactoring sess., CLaude's thinking revealed it had incorrectly assumed a shared config path was project-local rather than global. Had I not caught it in the thinking block before the tool calls executed, it would have rewritten three files--based on a false premise--requiring a full revert and re-run once the actual structure became apparent from the broken output.

Catching it in the thinking took 10 seconds. Missing it cost 20+ minutesof revert, re-explanation, and re-execution on previous occasions before I knew to watch for such presumptions.

The thinking block is the earliest possible intervention point. Once tool calls start executing on a wrong assumption, you're in damage-contrl mode. But the window to catch it is tiny--the block collapses the moment generation ends--and there's no way to retrieve it if you missed it or were reading something else at the time.

A persistent log removes that race condition entirely.

Additional Context

_No response_