API 400 "thinking blocks cannot be modified" permanently bricks session during agent activation (interleaved thinking + tool use)

Resolved 💬 5 comments Opened May 28, 2026 by Pirelli71 Closed Jun 30, 2026

Summary

Invoking a custom slash-command agent whose activation performs interleaved thinking + multiple tool calls reliably produces:

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

Once it occurs, the session is permanently unrecoverable — every subsequent user turn re-sends the same corrupted assistant message and returns the identical 400. Restore and Resume both fail the same way. The only escape is starting a brand-new session.

Environment

  • Claude Code 2.1.153
  • Model: claude-opus-4-7 (1M context)
  • Platform: macOS (Darwin 25.2.0)
  • Extended / interleaved thinking enabled

Repro

  1. Invoke a custom agent via slash command whose activation instructions trigger a chain of tool calls — e.g. read a config file, glob/search, a Bash command that exits non-zero, then more reads. This yields a multi-block first assistant turn: thinking → text → several tool_use blocks.
  2. Tool results return; the harness issues the next request.
  3. Request fails with 400 messages.1.content.5: thinking ... blocks cannot be modified.
  4. Any further user message returns the identical 400. Restore/Resume also fail.

In our case the failing turn happened to include a Bash tool call that exited non-zero (a wrong-path cat || find) mid-sequence, but the error is about thinking-block preservation, not the tool error itself.

Expected

thinking / redacted_thinking blocks from prior assistant turns are preserved byte-for-byte across tool-result round-trips, and the conversation continues.

Actual

A thinking block at messages[1].content[5] is modified by the harness before resend; the API rejects it; the session is bricked with no in-session recovery (Restore/Resume included).

Impact

  • The failure is sticky/terminal for the whole session, not a transient retry.
  • Reproducibly triggered by agents with heavy activation sequences (many interleaved thinking + tool blocks), but the root cause is block preservation across tool turns, not any specific agent.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗