Cancelling a parallel tool-call batch corrupts thinking blocks -> 400 "thinking blocks cannot be modified" permanently wedges the session

Problem

With extended thinking enabled, cancelling a batch of parallel tool calls (one tool errors → the rest are auto-cancelled) corrupts the thinking blocks of the in-flight assistant message. The next API request is rejected with a 400, and because the corrupted message stays in history, every subsequent turn re-sends it and re-fails — the session is permanently wedged.

Verbatim error (recurred on every turn afterward — including a plain text question and a slash-command invocation): `` API Error: 400 messages.1.content.54: thinking or redacted_thinking blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response. ``

Verbatim transcript leading up to it — a batch of parallel Bash tool calls, the first of which errored, cascading cancellations onto the rest: `` ⏺ Bash(safari-browser screenshot /tmp/plaud_search.png --url plaud 2>/dev/null && echo "saved") ⎿ Error: Exit code 1 ... ⏺ Bash(safari-browser js "1+1" --url plaud ...) ⎿ Cancelled: parallel tool call Bash(safari-browser screenshot /tmp/plaud_sea…) errored ⏺ Bash(echo "PLAIN_TEXT_TEST_NO_BROWSER") ⎿ Cancelled: parallel tool call Bash(safari-browser screenshot /tmp/plaud_sea…) errored ⎿ API Error: 400 messages.1.content.54: thinking or redacted_thinking blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response. `` — Source: Claude Code session transcript, 2026-05-29

Type

bug

Steps to reproduce (best-effort)

1. Extended thinking enabled (default in this session)
2. Model: claude-opus-4-7 (1M context)
3. In one assistant turn, issue a batch of parallel tool calls (here: ~10 Bash calls)
4. Arrange for the first call in the batch to error (here safari-browser screenshot … 2>/dev/null → Exit 1), so Claude Code auto-cancels the remaining parallel calls (Cancelled: parallel tool call … errored)
5. On the next API request, observe the 400

Expected

Cancelling parallel tool calls MUST preserve the assistant message's thinking / redacted_thinking blocks byte-for-byte (the API requires they stay identical when thinking + tool use is active), or discard the incomplete assistant turn cleanly. Either way the conversation should remain continuable.

Actual

A thinking block (here messages.1.content.54) is modified during the cancellation/reconstruction. The API rejects the request with 400. The bad message persists in conversation history, so every subsequent turn replays the same 400 — the user cannot even ask "what happened" or invoke a slash command. Only /clear or a new session recovers.

Impact

Total, unrecoverable session loss, triggered by a routine event (one tool in a parallel batch failing). High severity for any workflow that issues parallel tool calls with extended thinking on.

Environment

• Claude Code 2.1.153
• Model: claude-opus-4-7 (1M context), extended thinking enabled
• Platform: macOS (Darwin 25.5.0)