PaPoo
cover

TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したこと

この症状は、報告された2件の issue で同じエラー文字列として現れています。いずれも TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=142 messages=141 range=[118,142)) で始まり、スタックトレースは /$bunfs/root/src/entrypoints/cli.js を指しています。少なくとも issue 上では、別々の使い方に見える2件が同じ症状としてまとまっています。

まず切り分けの起点になるのは、​Claude Code の正常な会話中にこのエラーが出て、その後の振る舞いが不自然になるかどうかです。#84467 では、スキャナーからデータを取ろうとした途中で、モデルが「lower lesser models」に勝手に切り替わると報告されています。#84140 では、本人が所有するハードウェアへのアクセス支援を求めたところ、Claude がそれを脅威のように扱った、と書かれています。どちらも、単なる表示崩れではなく、会話の流れや判断が途中でおかしくなった場面で出ています。

issue 本文から読める範囲では、エラーは次の形です。

TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=142 messages=141 range=[118,142))
    at B5S (/$bunfs/root/src/entrypoints/cli.js:22795:8181)
    at vKf (/$bunfs/root/src

ここで確認できるのは、itemKeys と messages の長さが一致していないこと、そして keys=142 messages=141 range=[118,142) という差分が出ていることです。原因までは issue からは分かりません。少なくとも報告上は、ユーザー操作というより内部のリスト管理のずれが前面に出ています。

関連する issue は 2 件あり、代表扱いになっているのは #84140 です。#84467 は duplicate として閉じられており、コメントでも #84140 を追跡先にするよう案内されています。つまり、現時点で確認できる事実は「個別の操作ミス」ではなく、同系統の不具合として扱われている、というところまでです。

手元で確認できた環境情報は以下です。

[env_summary]
OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-10-02T08:55:12+09:00

この情報だけでは再現条件までは詰められません。したがって、現時点で書ける実務的な判断は、​同じエラー文字列が出ていて、会話の途中で挙動が崩れるなら、この issue 群と同系統の症状である可能性が高い、という程度です。逆に、似た場面でもこの文字列が出ていないなら、別件の可能性があります。


検証環境

OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-10-02T08:55:12+09:00

参照した Issue(anthropics/claude-code): #84467, #84140

同じ著者の記事