まず、自分の症状が同じかどうかは、エラーメッセージの形でかなり絞れます。今回のクラスタでは、TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出ていて、keys=... messages=... range=[...,...) のように itemKeys と messages の件数差まで表示されています。本文で確認できたのはこの型のエラーで、少なくとも issue 報告上は別件を含めて同じクラスタとして扱われていました。
報告されていた issue は 2 件です。#83109 では TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=325 messages=324 range=[279,325))、#81878 では TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=294 messages=293 range=[237,294)) が出ています。どちらも VirtualMessageList の件数不整合が前面に出ていて、少なくとも issue の記述を見る限り、利用者が「API が拒否した」「ツールが壊れた」と感じる状況の背後でこの例外が見えていました。
#83109 の本文では、表に出たメッセージは Anthropic API Error: Request False Flagged (req_011Cdc5YYrYws53v6o8LB5gF) でしたが、報告されたエラーとしては次のスタックが添えられています。
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=325 messages=324 range=[279,325))
at B9b (/$bunfs/root/src/entrypoints/cli.js:21727:8188)
at khf (/$bunfs/root/src
#81878 でも同じ種類のエラーが出ていました。
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=294 messages=293 range=[237,294))
at B9b (/$bunfs/root/src/entrypoints/cli.js:21727:8188)
at khf (/$bunfs/root/src
この 2 件から言えるのは、少なくとも issue の範囲では「API 固有の失敗」というより、VirtualMessageList の内部整合性が崩れたときに見えるエラーとして報告されている、という点です。どちらも解決済みではありますが、代表 issue に付いたコメントは “Closing for now — inactive for too long. Please open a new issue if this is still relevant.” だけで、本文中に具体的な修正内容や回避策はありませんでした。したがって、ここから確実に言えるのは「この症状は少なくとも過去に報告され、現在はその issue 自体はクローズされている」というところまでです。
手元で確認できる環境情報は次の通りです。ここは今回の検証条件として残しておきます。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-08T08:51:33+09:00
現時点では、この記事だけから再現手順や確実な対処法までは断定できません。もし同じ文字列で止まっているなら、少なくとも VirtualMessageList: itemKeys/messages length desync を含む issue 群と同系統と見て、必要なら新規 issue を切るのが筋です。既に close されている #83109 と #81878 の本文だけでは、恒久的な回避策は読み取れませんでした。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-08T08:51:33+09:00