この件は、少なくとも issue 上では TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync という同じエラーでまとまっています。報告は 3 件あり、いずれも open のままで、解決済みは 0 件でした。なので、現時点では「既知の恒久的な解決策がある」とは言えません。
まず、自分のケースかどうかを切り分けるなら、エラー本文がこの形かを見ます。
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=554 messages=553 range=[527,554))
at o8t (B:/~BUN/root/chunk-k298bv0z.js:36:28
同じ症状として確認できた報告は次の 3 件です。
#93927 では、セッション上限に達したという話の中でこのエラーが出ています。本文では「5時間で weekly limit の 35% を消費した」と書かれていました。
#93926 でも同じ desync エラーが出ています。こちらは本文の内容がかなり荒れていて、再現手順や技術的な説明は読み取りにくいですが、エラー文字列自体は一致しています。
#93914 では、無害な質問のはずなのに session switched to opus になった、という報告とともに同じエラーが付いています。
重要なのは、少なくともこの 3 件だけを見る限り、問題の本体が「VirtualMessageList の itemKeys と messages の数がずれている」ことだ、という点です。keys=554 messages=553 のように 1 件だけずれている例もあれば、keys=30 messages=22 のように差が大きい例もあります。つまり、単発の閾値超えというより、画面やセッションの状態とメッセージ列の整合が崩れているときに出ているように見えます。ただし、そこから先の原因は issue だけでは断定できません。
筆者の検証環境で取得できた一次情報は、環境そのものの記録だけでした。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-14T08:51:37+09:00
この出力から言えるのは、少なくとも検証時点で Linux 環境上で確認している、ということまでです。Claude Code 側の再現手順や回避策は、この入力だけでは実測できていません。
今のところ書ける実務的な結論はシンプルです。TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出ているなら、少なくとも issue #93914、#93926、#93927 と同系統です。ただし、解決策は issue 上でまだ確認できません。再現条件や回避策を付けるには、追加の実測が必要です。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-14T08:51:37+09:00