API 400 "thinking blocks cannot be modified" on a fresh session during a multi-tool turn

Resolved 💬 1 comment Opened May 30, 2026 by regie-d Closed Jul 3, 2026

Version: 2.1.154
Platform: macOS (Darwin 25.5.0, Apple Silicon / M4)
Model: Opus 4.8 (claude-opus-4-8)

What happened

Brand-new session. Single user request (build a PowerPoint slide). On the assistant's first turn it made many tool calls with interleaved thinking blocks between them. The follow-up API call (sending tool results back) failed with:

API Error: 400 messages.1.content.23: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.

Why this looks like a harness bug, not user error

  • messages.1 is the first assistant turn — there is no prior history to corrupt.
  • No message editing, no Esc-rewind, no --resume/--continue, no model switch, no /compact.
  • content.23 is a thinking block in a 24+ block turn (interleaved thinking across many tool calls).
  • Config ruled out: no MAX_THINKING_TOKENS / interleaved-thinking env vars set; user hooks are only a SessionStart context-injector and a browser_close denier — neither touches assistant content.

Expected

Thinking blocks round-trip unmodified across the tool-use loop.

Actual

A thinking block in the latest assistant message is altered before resend, triggering the 400 and stalling the turn.

Appears to be an interleaved-thinking + long-agentic-turn interaction in the CLI's message reconstruction.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗