[Bug] Extended thinking + AskUserQuestion causes unrecoverable 400: thinking blocks cannot be modified

Bug Description
Title: Extended thinking + AskUserQuestion wedges session with unrecoverable 400 (thinking blocks cannot be modified) Claude Code version: 2.1.154 — Opus 4.8 (1M context), medium effort Platform: macOS (Darwin 25.2.0), zsh Severity: High — a single malformed turn permanently wedges the conversation; every subsequent user message re-throws the same 400. Only /clear recovers it. --- Summary When extended thinking is on and a skill invokes AskUserQuestion mid-turn, consuming the user's answer can fail with a 400 that the latest assistant message's thinking block "cannot be modified." Worse, the failed turn is retained as the latest assistant message, so every subsequent user message reproduces the identical 400 — the session is wedged until /clear. --- What happened (original failure) 1. Long-running session, started with --dangerously-load-development-channels (experimental server:claude-peers inbound messages active), deep into the transcript with multiple prior thinking blocks. 2. Ran a skill-backed slash command (/autoloop-slice-prep 65) with extended thinking enabled. 3. The skill invoked AskUserQuestion to disambiguate a target. User selected an answer. 4. The turn consuming the answer failed with: API Error: 400 messages.1.content.3: 'thinking' or 'redacted_thinking' blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response. 5. User then sent a new message (huh?). It produced the identical 400 — the broken turn had become the permanent "latest assistant message," so each new message rebuilt on it and re-failed. --- Expected - The AskUserQuestion answer-consume path should re-send prior-turn thinking/redacted_thinking blocks verbatim, never modifying them. - Even when a turn 400s, the client should not leave the conversation in a state where all future messages reproduce the error. A failed turn should be discardable/rolled back without requiring /clear. Actual - The continuation modifies a pinned thinking block → 400. - The failed turn persists as latest-assistant → every following message re-throws the same 400 → session wedged until /clear. --- Likely root cause (hypothesis) The AskUserQuestion answer-resume path appears to rebuild the in-flight assistant message and mutate/re-emit its thinking block rather than passing it through unchanged. Because extended-thinking blocks are pinned server-side, any edit fails closed with a 400. The wedge is a separate, compounding bug: the 400'd turn is kept as latest-assistant instead of being rolled back. --- Reproduction status - Original failure: long-running session, channel flag on, many prior thinking blocks. 400 fired on the AskUserQuestion answer-consume turn, then wedged permanently. - Attempted minimal repro: fresh claude session, no channel flag, thinking on, AskUserQuestion invoked mid-turn (via an underspecified request that forced a clarifying question) and answered. Did NOT reproduce — answer consumed normally, turn continued, skill loaded. - Conclusion: Not deterministic from {thinking on + AskUserQuestion mid-turn + answer selected}. The trigger is state-dependent — implicating either the experimental inbound-channel mode, accumulated transcript/thinking-block history, or their interaction. Could not isolate to a single variable from the user side (the clean session changed two variables at once: flag off and short transcript). --- Ask for triage 1. The attached transcript from the failing session is the key artifact — please identify which prior thinking/redacted_thinking block the answer-consume turn attempted to modify, and why. 2. The wedge half stands regardless of the initial trigger: a 400'd turn should not be retained as latest-assistant such that every subsequent message re-fails. Please treat that as a separate, independently-fixable defect.

Environment Info

• Platform: darwin
• Terminal: vscode
• Version: 2.1.154
• Feedback ID: 5d731d31-98e5-4f2b-8126-47f5b2d0719f

Errors

[]