tool call could not be parsed (retry also failed) が出るときに見えていたことまず、この症状に当てはまるかどうかはかなりはっきりしています。Claude Code 側の turn がいったん考えたあとで落ち、The model's tool call could not be parsed (retry also failed). という文言と一緒に失敗する。報告されているものでは、Claude Desktop app の Code tab で再現した例があり、#64658 では Desktop app version 1.9659.4 の Opus 4.8 で頻発すると書かれていました。別の報告、#68529 でも Opus 4.8 (1M) で同じ系統の失敗が出ていて、こちらは tool result のあとに次の assistant turn が失敗したり、tool call が何も返さないように見えたりしています。
手元で確認できた一次情報は環境の記載だけです。少なくとも、今回の検証環境は Linux 上で動いていました。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-11T08:54:36+09:00
なので、ここで書けるのは「この文字列が出る症状は実際に issue に上がっている」という範囲までです。原因の断定や、これで必ず直るという手順までは確認できていません。
切り分けとしては、少なくとも報告上は次の2つの見え方があります。ひとつは、考えているように見えた turn が最後に parse 失敗で落ちるパターンです。もうひとつは、tool call がそもそも結果を返さない、あるいは結果が黙って消えるように見えるパターンです。#68529 では、成功した tool result のあとに次の assistant turn で失敗しやすいと書かれていました。
コメント欄で共有されていた回避策としては、Opus 4.8 から claude-opus-4-7 に切り替えると回避できた、という報告があります。ただし、これは issue コメントの再現報告であって、こちらで実測した修正ではありません。現時点では「その環境では回避できた人がいた」以上のことは言えません。
もし手元で同じ文字列を見ているなら、確認したいのは次のあたりです。Desktop app の Code tab なのか、CLI なのか。使っているモデルが Opus 4.8 なのか。長めの agentic session で起きているのか。日本語テキストとコードが混ざる会話かどうか。これらは、少なくとも issue の報告内容と重なっています。逆に、ここから先の原因特定は、渡された情報だけでは分かりません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-11T08:54:36+09:00