claude-code - 💡(How to fix) Fix AskUserQuestion: cancelling during extended thinking poisons the whole session with 400 'thinking blocks cannot be modified' (2.1.153); concurrent prompts overwrite each other

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

When extended thinking is enabled, cancelling/rejecting an AskUserQuestion prompt poisons the entire session: the next request fails with API Error: 400 ... 'thinking' or 'redacted_thinking' blocks in the latest assistant message cannot be modified, and then every subsequent message returns the same 400. The session is unrecoverable — the only escape is /exit.

There is a second, contributing bug that makes the cancel far more likely: multiple AskUserQuestion tool calls emitted in a single streamed assistant response render concurrently and overwrite each other on screen, so the visible question changes while the user is mid-answer — prompting an instinctive Escape/cancel, which then triggers the 400 above.

Error Message

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

Root Cause

After this, every subsequent user message returns the identical 400, because the corrupted assistant turn (with the modified signed thinking block) stays in history and is re-sent on each request. /exit is the only way out. (/clear or a rewind to before the poisoned turn would also work but most users don't discover that.)

Code Example

AskUserQuestion (3 questions)   13:17:04   <- prompt A, never answered yet
  assistant Read                13:17:26   <- continues WITHOUT a tool_result for A
  assistant (thinking)
AskUserQuestion (2 questions)   13:17:39   <- prompt B fires; A still pending
  assistant Read                13:18:03
...
tool_result for prompt A        -> "the tool use was rejected"
tool_result for prompt B        -> "the tool use was rejected"

---

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

Summary

When extended thinking is enabled, cancelling/rejecting an AskUserQuestion prompt poisons the entire session: the next request fails with API Error: 400 ... 'thinking' or 'redacted_thinking' blocks in the latest assistant message cannot be modified, and then every subsequent message returns the same 400. The session is unrecoverable — the only escape is /exit.

There is a second, contributing bug that makes the cancel far more likely: multiple AskUserQuestion tool calls emitted in a single streamed assistant response render concurrently and overwrite each other on screen, so the visible question changes while the user is mid-answer — prompting an instinctive Escape/cancel, which then triggers the 400 above.

Environment

  • Claude Code 2.1.153 (native install) — latest at time of filing
  • macOS (Darwin 25.x)
  • Extended thinking enabled, Auto permission mode
  • Reproduced across three consecutive sessions in an ~18-minute window

Bug 1 — concurrent AskUserQuestion prompts overwrite each other

In one streamed assistant response, the model emitted more than one AskUserQuestion tool_use interleaved with other tool calls, without waiting for an answer to the first. Inspecting the session transcript (~/.claude/projects/<proj>/<id>.jsonl) via the uuid/parentUuid chain:

AskUserQuestion (3 questions)   13:17:04   <- prompt A, never answered yet
  assistant Read                13:17:26   <- continues WITHOUT a tool_result for A
  assistant (thinking)
AskUserQuestion (2 questions)   13:17:39   <- prompt B fires; A still pending
  assistant Read                13:18:03
...
tool_result for prompt A        -> "the tool use was rejected"
tool_result for prompt B        -> "the tool use was rejected"

Both AskUserQuestion blocks were pending simultaneously. The second prompt rendered over the first while the user was still answering it → the question visibly changed mid-interaction.

Expected: AskUserQuestion should be a hard barrier — ask one, stop, wait for the answer before any further tool call or a second AskUserQuestion.

Bug 2 — cancelling AskUserQuestion during extended thinking → unrecoverable 400

Cancelling/rejecting the AskUserQuestion produces:

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

After this, every subsequent user message returns the identical 400, because the corrupted assistant turn (with the modified signed thinking block) stays in history and is re-sent on each request. /exit is the only way out. (/clear or a rewind to before the poisoned turn would also work but most users don't discover that.)

Repro steps

  1. Start a session with extended thinking enabled.
  2. Get the assistant into a flow that emits an AskUserQuestion (e.g. an interactive spec/PRD-iteration flow). Bug 1 makes this reliably produce multiple prompts.
  3. Cancel/Escape the question (or reject the tool use) — natural reaction when the prompt changes under you.
  4. Send any further message → 400 ... thinking blocks cannot be modified.
  5. Every message thereafter → same 400. Session dead.

Expected

Cancelling an AskUserQuestion should leave the session usable. The client should drop/strip the un-finalised assistant turn (or its stale-signature thinking blocks) rather than re-sending a modified thinking block. This mirrors the 2.1.152 fix ("sessions getting stuck after a model or login switch left stale thinking-block signatures in history; now stripped proactively") — but that fix only triggers on a model/login switch, not on AskUserQuestion cancel, so this path remains broken in 2.1.153.

Impact

High. A single mis-click/Escape on a question — especially when Bug 1 makes the prompt move under the user — permanently bricks the session and loses in-progress context unless the user knows the /exit (or /clear/rewind) escape hatch.

Related

  • #10199 (open) — general thinking-block 400
  • #12743, #24662, #26684, #21289, #22217 (closed) — thinking-block / unrecoverable-session 400s via other triggers (compaction, empty content block, 100% context). This issue adds the AskUserQuestion-cancel trigger and the concurrent-AskUserQuestion contributing factor, confirmed on 2.1.153.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING