この症状で報告されているのは、TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=126 messages=125 range=[118,126)) というエラーです。Issue はどちらも closed ですが、内容はかなり近く、#87541 では「Opus 5 safety filter triggering false positives on consecutive requests」、#87543 では「False Positive in Opus Security Scan」として出ています。どちらも、報告されたエラー文字列は同じでした。
まず、自分のケースかどうかを見分けるなら、出力にこの文字列がそのまま出ているかを確認するのが早いです。Issue に載っているエラーは次の形でした。
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=126 messages=125 range=[118,126))
at nPv (/$bunfs/root/src/entrypoints/cli.js:23184:8181)
at NAm (/$bunfs/root/src
少なくとも、この報告から読み取れるのは、itemKeys と messages の長さが一致していない、という内部エラーだという点です。keys=126 messages=125 とあり、1 件ずれています。ただし、Issue だけではこのずれが何に起因するかまでは断定できません。報告タイトルを見る限り、Opus 5 の safety filter / security scan の false positive と結びつけて投稿されたようですが、実際の原因の切り分けはこの資料だけでは分かりません。
代表 issue のコメントには、解決策として使える具体的な手順は書かれていませんでした。見えているのは、短いリアクションと、しばらく非アクティブだったために close された、という事実だけです。
Closing for now — inactive for too long. Please [open a new issue](https://github.com/anthropics/claude-code/issues/new/choose) if this is still relevant.
手元で確認できる環境情報は次のとおりです。この記事で言えるのは、少なくとも Linux 上での検証時点では、問題の切り分けに使える一次情報がこの程度だった、ということまでです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-09T08:54:51+09:00
現時点で実測に基づいて言える対応は多くありません。少なくとも、同じエラー文字列が出ていて、しかも Opus 5 safety filter や Opus Security Scan の false positive と一緒に再現しているなら、#87541 と #87543 の系統に近い症状と考えてよさそうです。逆に、この文字列が出ていないなら、別件の可能性があります。
新しく報告するなら、エラー全文と、どの操作の直後に出たかをそのまま添えるのがよさそうです。Issue 側でも、手元のログのこの断片以上の切り分け材料は確認できませんでした。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-09T08:54:51+09:00