このエラー名がそのまま出ているなら、少なくとも「Claude Code のセッション内部で、保持しているメッセージ数とキー数がずれた」状態に遭遇している可能性があります。今回見ている issue では、itemKeys/messages length desync が複数報告されていて、しかも症状の出方が少し違います。
たとえば #90480 では、リファクタリング用の orchestrator と subagent を使っている途中で safeguard penalty が出たと報告されています。本文では「理由が不明だった」「Fable5 が自分で refactoring plan を組んだ」と書かれていました。
#90276 では、agents.md の仕様に従わない挙動が続いたあとにこのエラーが出ています。
#90011 は少し違っていて、見た目は usage limit の異常消費ですが、同じエラー文字列が併記されています。
つまり、少なくとも issue 群を見る限りでは、これは単なる表示崩れではなく、複数の会話要素を持つセッションで内部状態が食い違ったときに現れているように見えます。とはいえ、原因までは断定できません。報告された内容だけでは、Claude Code 側のバグなのか、特定の運用パターンなのかは分かりません。
代表 issue に付いたコメントでは、macOS 上の Claude Code 2.1.247、Claude Max、Claude Opus 5 の 1M context window、高 effort、Auto mode、main session を orchestrator にして subagents を使う構成で、同じ異常消費が再現したとされています。これも「この系統の症状が、会話の分岐や subagent を多用する構成で起きているかもしれない」という程度までは言えますが、ここから先は推測になります。
筆者の検証環境で確認できたのは、環境情報だけです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-08-29T08:50:50+09:00
この出力だけでは再現検証まではできていません。なので、現時点で言えるのは「同じエラー名を含む issue が複数あり、orchestrator / subagent を含む会話構成や、usage の異常消費と一緒に観測されている」というところまでです。
自分のケースかどうかを見分けるなら、まずは次の2点です。
ひとつは、セッション内で subagent や分岐の多い会話をしていたか。もうひとつは、急に usage が進んだり、理由の説明なしに safeguard penalty や制限に触れたかです。これらが重なっていて、同じ TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出ているなら、この issue 群とかなり近い症状と思われます。
ただし、回避策として確立したものは、今回渡された情報の中にはありません。未解決として扱うのが安全です。
#90480
#90276
#90011
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-08-29T08:50:50+09:00