keys=249 messages=248 が出たときに見ることまず、この症状が自分のケースかどうかは、エラー本文の形でほぼ見分けられます。今回集まっている issue では、いずれも TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync に続いて、keys=... messages=... range=[...,...) という不一致が出ています。たとえば #79204 では keys=249 messages=248 range=[211,249)、#79194 では keys=107 messages=106 range=[84,107)、#79182 では keys=520 messages=518 range=[460,520) でした。keys と messages の数が 1 ずれ、しかも range が終端にかかっているのが共通点です。
この共通点だけを見ると、ユーザーがやっていた作業はかなり幅があります。計算作業をしていた人もいれば、DB の fine-tuning、防御的なセキュリティ作業、通常のデプロイ作業、Google Calendar 連携の途中で出た人もいます。つまり、少なくともこの issue 群だけからは「特定の作業内容が原因」とは言えません。むしろ、作業内容が違っていても同じ内部エラーに落ちている、という見え方です。
報告の中には、エラーの直後にモデルが Opus に切り替わった、あるいは安全機構が誤検知したように見える、という説明もありました。とはいえ、確認できる一次情報としてはあくまで VirtualMessageList: itemKeys/messages length desync で、原因の断定まではできません。現時点では、Claude Code 側のメッセージ一覧の整合性が崩れた状態で TelemetrySafeError になっている、と読むのがいちばん近いです。
手元で確認できた検証環境は次のとおりです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-04T08:50:54+09:00
ただし、この環境出力だけでは再現手順や回避策までは出せません。issue 側にも、確立した修正手順は見当たりませんでした。代表 issue のコメントも「しばらく inactive だったので閉じる。まだ関連があるなら新しい issue を開いてほしい」という内容で、解決策の提示ではありませんでした。
なので、この記事で言える範囲はここまでです。TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出たら、少なくとも同種の報告群と同じ症状に入っています。特に keys と messages の数が 1 ずれているか、range が末尾にかかっているかを見れば、#79204、#79194、#79182、#79141、#79091、#79401 と同じ系統かどうかを判断できます。
修正済みかどうかは、今回与えられた情報だけでは分かりません。再発しているなら、新しい issue として出して、実際に出た TelemetrySafeError の全文を添えるのが現実的です。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-04T08:50:54+09:00
参照した Issue（anthropics/claude-code）: #79204, #79194, #79182, #79141, #79091, #79401