API 400 "thinking blocks cannot be modified" permanently bricks session during agent activation (interleaved thinking + tool use)
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
- 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_useblocks. - Tool results return; the harness issues the next request.
- Request fails with
400 messages.1.content.5: thinking ... blocks cannot be modified. - 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.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗