claude-code - 💡(How to fix) Fix Extended thinking: signed thinking block 'cannot be modified' (400) permanently wedges session

Summary

With extended/interleaved thinking enabled, Claude Code intermittently replays a modified signed thinking block in the latest assistant message, producing:

API Error: 400 messages.N.content.M: `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 this occurs the corrupted assistant message is persisted in the transcript, so every subsequent request re-sends it and fails identically. The session becomes permanently unrecoverable — re-prompting and "try again" both reproduce the same 400. A full /clear is the only reliable escape (/rewind to before the failed turn may also work).

Environment

• Reproduced across Claude Code 2.1.143, 2.1.150, 2.1.153 (currently on 2.1.154).
• macOS (darwin 25.5.0).
• Extended/interleaved thinking enabled.

Impact

Silent, repeated total loss of a working session on long-running tasks. Especially costly on Opus, where extended thinking is core to the product — the only durable user-side workaround is disabling thinking, which is a capability downgrade users shouldn't have to accept.

Evidence

Observed in 5 separate session transcripts. The error references a thinking block (the cited content.M is always a thinking block), and the same fingerprint recurs:

• messages.19.content.21 (recurs across multiple sessions)
• messages.1.content.7
• messages.327.content.14

(messages.N.content.M indexes the API request payload, not any project file.) The 400 is raised before model reasoning starts, so any "self-analysis / retry" inside the same session just resends the invalid transcript and fails again.

Reproduction

Trigger: a tool-heavy assistant turn while extended thinking is on, where the harness reconstructs that assistant message after it was first emitted. Observed concrete triggers:

1. Background tasks — a run_in_background Bash command whose async completion notification re-enters the originating assistant turn; on resume the harness replays that turn's thinking block modified → 400.
2. Parallel tool-call cancellation — a batch of parallel tool calls where one errors and cancels its siblings (Cancelled: parallel tool call ... errored); the next turn 400s on the thinking block.
3. Plain tool-heavy turn — in one session the 400 fired immediately after a single file-write tool call on a turn that contained thinking blocks. So the trigger is more general than (1)/(2).

Expected behavior

Signed thinking / redacted_thinking blocks must be persisted and replayed byte-for-byte unmodified across all harness operations — including background-task resumption, tool-call cancellation, and normal multi-tool turns. The client should never emit a modified thinking block.

Actual behavior

The harness emits a modified thinking block on the latest assistant message, the API rejects it with a 400, and the session is permanently wedged with no in-session recovery.