まず、このエラーが出るケースかどうかを切り分けます。手元の issue 報告では、どれも thinking か redacted_thinking のブロックが、最新の assistant message に入ったあとに壊れています。しかも一度壊れると、そのセッションの続行や再開がずっと失敗し続けます。
たとえば #63258 では、バックグラウンド実行した subagent が最初のターンで即座に落ちています。Explore agent でも一般の Agent でも同じで、ツール呼び出しに進む前にこの 400 が返っていました。再試行しても同じでした。
#63227 では、カスタム slash-command agent の activation 中に、thinking と複数の tool call が交互に入る構成で再現しています。ここでは一度壊れると、Restore でも Resume でも戻らず、新しいセッションを始める以外に抜け道がないと報告されています。
#63229 は、extended thinking を有効にしたままセッション途中でモデルを切り替えたときに、会話全体が壊れるという報告です。以後の入力は毎回同じ 400 を返し、CLI 内から復旧できないとされています。
#63147 は、extended-thinking セッションを resume するときに起きます。tool call を伴った履歴を再開したあと、続行のたびに同じエラーになり、やはりセッションが使えなくなります。
共通しているのは、単発の一時的な失敗ではなく、会話履歴のどこかにある assistant message の thinking 系ブロックが、送信し直す過程で「元の応答のまま」でなくなってしまっている点です。issue の本文では、thinking の中身が空になっているのに signature は残る、という観察も出ています。ここはかなり重要そうですが、筆者の環境では未検証なので、現時点では「そう報告されている」とだけ書きます。
実際にこの症状を示すエラー文は、issue では次の形でした。
API Error: 400 messages.1.content.5: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.
別の報告では、同じ趣旨のメッセージが messages.1.content.14 や messages.75.content.15 のように別の位置で出ています。番号は違っても、内容は同じです。つまり、特定の行番号そのものが原因というより、会話履歴の再構成時に thinking ブロックが壊れていると考えるのが自然です。
今回こちらで実際に取得できた一次情報は、検証環境の日時だけでした。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-03T08:50:56+09:00
この出力から分かるのは、少なくとも筆者の確認時点では Linux 環境だったことだけです。Claude Code のどの版で起きるか、どの設定が直接の引き金かは、この一次情報だけでは断定できません。issue 群では 2.1.153 や Opus 4.7 / 4.8、extended thinking、tool use、resume/continue、background subagent、mid-session model switch などが絡んでいますが、これはあくまで各 issue の報告範囲です。
もし自分のケースが似ているかを見るなら、次のような挙動が揃っていればかなり近いです。ひとつでも当てはまるだけでは足りませんが、複数重なるほど怪しくなります。
現時点で issue から読める範囲では、恒久的に壊れたセッションは新規セッションを作る以外に抜けられない例が複数あります。Restore / Resume でも戻らない、という報告が重なっています。そこは重く見たほうがよさそうです。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-03T08:50:56+09:00
参照した Issue（anthropics/claude-code）: #63147, #63258, #63227, #63229