[BUG] CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 breaks Stop-hook/background evaluator requests: omits `thinking` while still attaching `clear_thinking_20251015`

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest matches below — none cover this specific trigger)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Environment

• Version: 2.1.228
• Platform: macOS (also reproduces through a self-hosted Anthropic-compatible proxy, see below — not proxy-specific, see root cause)
• Config: ~/.claude/settings.json had "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1" set in the env block

What's Wrong?

With CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 set, Claude Code's background/internal requests (confirmed: the Stop-hook evaluator that runs after each turn to check hook conditions, e.g. session-tracking hooks and the /goal command's condition-checker) fail with:

API Error: 400 `clear_thinking_20251015` strategy requires `thinking` to be enabled or adaptive

Root Cause (confirmed via request-level inspection)

Claude Code's internal background/hook-evaluator requests automatically attach the real Anthropic context-editing strategy clear_thinking_20251015 (used to prune old thinking blocks and save tokens on long-running sessions) — this is a real API feature that requires the request to also include a thinking block (type: enabled or type: adaptive).

When CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 is set, Claude Code correctly omits adaptive thinking from these background requests — but the request still attaches clear_thinking_20251015 regardless, producing a request the Anthropic API is guaranteed to reject. The setting is intended to control the interactive thinking mode; it isn't meant to apply to (and shouldn't break) CC's own internal housekeeping requests.

I confirmed this is not proxy/environment-specific: inspecting logs on a self-hosted Anthropic-compatible proxy in front of this session showed the proxy passes thinking/context_management blocks through transparently — requests succeed (200) whenever the client includes a thinking block, and only fail when the client (Claude Code, under this setting) omits it.

Fix applied locally: removing CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING from settings.json resolves it immediately (verified: Stop hooks succeed, no more 400s).

Suggested Fix

Either:

1. Don't attach clear_thinking_20251015 to a request unless thinking is also being included on that same request, or
2. When CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING is set, only suppress adaptive thinking on the interactive/main-loop request path — not on internal background/hook-evaluator requests, which should keep whatever minimal thinking config clear_thinking_20251015 requires (or simply not request clear_thinking_20251015 on those calls at all).

Repro

1. Set CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING: "1" in ~/.claude/settings.json's env block.
2. Register any Stop hook (a plain command hook is enough — e.g. the built-in session-tracking hooks, or run /goal <condition> which registers a session-scoped Stop hook).
3. Complete a normal turn.
4. Observe: Stop hook error: Hook evaluator API error: API Error: 400 'clear_thinking_20251015' strategy requires 'thinking' to be enabled or adaptive — non-fatal (the session continues), but the hook's own condition-check silently fails every time.

Related (not duplicates — different specific triggers)

• #11690 / #11533 / #11534 — same error text, different mechanism (an A/B-testing bug from Nov 2025, fixed in v2.0.42–2.0.44). This report reproduces fresh on 2.1.228 via a different, still-live trigger.
• #69379 — same class of bug (CC omitting thinking on certain internal requests against endpoints that require it) but a different specific trigger (third-party endpoints requiring thinking: enabled unconditionally) and auto-closed stale without a fix, not actually resolved.