[BUG] CLAUDE_CODE_EXTRA_BODY thinking config breaks WebSearch and WebFetch on Opus 4.7 [1m]

Status Open
Reported on v2.1.131
Maintainer reply None cached
Activity 5 comments · opened May 7, 2026

Preflight Checklist

  • [x] Searched existing issues — related but distinct: #50100, #51212 (Bedrock; closed/locked), #49322 / #49268 (the bug this config works around)
  • [x] Single bug report
  • [x] Latest Claude Code (2.1.131)

What's Wrong?

I run with the following in ~/.claude/settings.json as a workaround for #49322 (thinking summaries not rendering in VS Code extension on Opus 4.7):

"env": {
  "CLAUDE_CODE_EXTRA_BODY": "{\"thinking\":{\"type\":\"adaptive\",\"display\":\"summarized\"}}"
}

This restores thinking summaries in the VSCode extension. But it also breaks WebSearch and WebFetch every time, because the harness forwards CLAUDE_CODE_EXTRA_BODY to internal sub-requests that can't accept those params:

WebSearch — uses tool_choice: {type: "tool", name: "web_search"} to force the search tool:

API Error: 400 Thinking may not be enabled when tool_choice forces tool use.

WebFetch — spawns a sub-call to a smaller summarization model that doesn't accept adaptive thinking:

API Error: 400 adaptive thinking is not supported on this model

So the user is stuck between two bugs: drop the env var → no thinking visible (#49322); keep it → no web tools.

What Should Happen?

CLAUDE_CODE_EXTRA_BODY is documented as a top-level request override. The harness should either:

  • Strip incompatible fields (e.g. thinking) from sub-requests that use forced tool_choice or that target models without adaptive-thinking support, or
  • Make it possible to scope CLAUDE_CODE_EXTRA_BODY to top-level model calls only.

Ideally, fixing #49322 would also remove the need for this workaround entirely.

Steps to Reproduce

  1. ~/.claude/settings.json includes:

``json
"env": { "CLAUDE_CODE_EXTRA_BODY": "{\"thinking\":{\"type\":\"adaptive\",\"display\":\"summarized\"}}" }
``

  1. /model claude-opus-4-7[1m]
  2. Call WebSearch with any query → 400 above.
  3. Call WebFetch on any URL → 400 above.
  4. Remove the env var, restart, retry → both tools work, but #49322 returns (no thinking summaries in VSCode extension).

Claude Model

Opus (claude-opus-4-7[1m])

Claude Code Version

2.1.131

Platform

Anthropic API (direct)

Operating System

macOS 26.4.1 (Darwin 25.4.0 arm64)

Terminal/Shell

VS Code extension, zsh

Additional Information

Related: #49322, #49268 (the thinking-summary rendering bug this config works around), #50100, #51212 (Bedrock variants of the same [1m] + thinking incompatibility).

View original on GitHub ↗

4 Comments

ojura · 3 months ago

Filed #59844 proposing the structurally safer fix: drop the !getIsNonInteractiveSession() gate in the CLI's display = "summarized" assignment (or, as a fallback, default --thinking-display summarized in the VS Code extension's spawn args). Both options set only display, never type, so the CLI's per-request q.type !== "disabled" gate continues to drop the entire thinking field for WebSearch / WebFetch / forced-tool-use paths and incompatible-model sub-calls. Verified locally: claude --print --thinking-display summarized --allowed-tools WebSearch "..." produces 5+ API requests, all 200, no 400 Thinking may not be enabled when tool_choice forces tool use.

Replacing CLAUDE_CODE_EXTRA_BODY with either of the proposed fixes resolves this issue as a side effect.

Disclosure: written with Claude Opus 4.7.

michprev · 2 months ago

still experiencing this issue with Claude 2.1.169

naiimic · 1 month ago

Still reproduces on 2.1.198 with claude-fable-5, subscription auth, macOS + Ubuntu

Denny-g6labs · 1 month ago

Same here. I want to see the thinking text in VSCode (the expandable button), so I enabled it by setting CLAUDE_CODE_EXTRA_BODY (summary), but that causes the 404 on we searches. I don't know why the hell we don't see the thinking processes by default instead of just how many tokens have been used.

Showing cached comments. Read the full discussion on GitHub ↗