thinking blocks ... cannot be modified が出てセッションが戻らないときこの症状に心当たりがあるなら、まず見分けたいのは「一度だけ 400 が出た」のか、「その後ずっと同じ 400 で詰まる」のかです。今回の issue では、後者が報告されています。途中で止まった会話が、その後の送信でも毎回 thinking 系のブロック不正として落ち続ける、という流れです。
報告されている代表例は #63374 と #63410 です。どちらも最終的には同じエラー文に行き着きます。
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.`
#63374 では、interleaved thinking が流れている最中に新しいプロンプトを入れると、ハーネス側に「最後の content block が thinking の assistant メッセージ」が保存されてしまい、その後の API リクエストがずっと同じ不正メッセージを再送して失敗すると説明されています。ここでの引き金は「ストリーミング中の割り込み」です。
#63410 では、長く続いたセッションが extended thinking と tool use の組み合わせで壊れ、以後の turn がすべて 400 になると報告されています。こちらは途中のトリガーが割り込みだけではなく、別のパターンでも同じ壊れ方をすることを示しています。コメントでは、並列ツール呼び出しの一部が失敗して batch がキャンセルされた結果、同じ終端状態になったという再現も挙がっています。
つまり、読者側で確認したいのは「会話が途中で切れた直後から、毎回同じ thinking blocks ... cannot be modified が返るか」です。もしそうなら、単発の入力ミスではなく、セッション側に壊れた assistant message が残っている可能性があります。少なくとも issue 上では、その状態に入ると会話は回復せず、以後のユーザー入力も同じ messages.N.content.M で 400 になるとされています #63410。
筆者の環境で実際に取得できた一次情報は環境条件だけでした。再現手順や回避策までは確認していません。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-05T08:50:54+09:00
現時点で、少なくとも issue から言えるのは次の範囲です。interleaved thinking や extended thinking を使っている会話で、ストリーム中断や並列ツールのキャンセルが起点になり、最新 assistant message の thinking / redacted_thinking ブロックが壊れることがある。その結果、Claude Code が同じセッションを再送し続け、400 で詰まり続ける、ということです。どの条件で必ず起きるか、どの操作で復旧できるかは、この報告だけでは分かりません。
もし同じ文字列が出ていて、しかも毎回同じ場所の messages.N.content.M で落ちるなら、別件ではなくこの症状クラスタに近いと見てよさそうです。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-05T08:50:54+09:00