#bug

この症状は、Claude Code の内部で `VirtualMessageList: itemKeys/messages length desync` が起きたときのものです。今回の報告では、複数の issue で同じエラー文字列が出ています。 切り分けの起点はかなり単純で、エラー本文に次の形が入っているかどうかです。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=59 messages=58 range=[19,59)) TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=191 messages=190 range=[163,191)) TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=291 messages=290 range=[273,291)

この症状は、少なくとも GitHub Issue の報告上では、Claude Code の実行中に `TelemetrySafeError: task output swap refused (output is an unregistered symlink made during this session)` が返っているケースです。報告は2件あり、[#91435](https://github.com/anthropics/claude-code/issues/91435) は closed、[#91042](https://github.com/anthropics/claude-code/issues/91042) は open です。どちらも同じエラー文字列を含んでいますが、原因の説明や恒久的な解決策は issue 本文だけでは確定していません。 まず、あなたのケースがこのクラスタに当たるかを見るなら、エラー文に次の部分が入っているかを確認します。 ```text TelemetrySafeError: task output swap refused (output is

「Claude Code が `gh` を呼ぼうとした」という症状だけを見ると、GitHub CLI が入っている前提の話に見えます。ですが、今回の issue 群では少し事情が違います。 ```shell Bash(gh issue view 17033 --repo FreeCAD/FreeCAD --comments) ⎿ Error: Exit code 127 /usr/bin/bash: line 1: gh: command not found ``` この報告から分かるのは、少なくともその環境では `gh` が見つからず、しかもユーザーが止めたい対象は Git コマンドだけではなく GitHub 系の操作も含んでいた、ということです。報告者自身も「Claude should not run any commands that interacts with git. Including github commands.」と書いています。つまり、`git` だけ禁止しても、`gh` を使った GitHub 操作までは止め切れていません。 もう一方の [#87795](ht

この症状は、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` というエラー文字列で報告されています。今回まとまっていた issue は 2 件で、どちらも open のままで、解決済みの報告はありませんでした。つまり、少なくとも今回の材料だけでは「これで直る」と言い切れる定番解はありません。 まず、自分のケースかどうかを切り分けるなら、表示されているエラー本文がほぼそのまま一致するかを見ます。報告されていた文字列は次の通りです。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=855 messages=854 range=[807,855)) at jQt (B:/~BUN/root/chunk-w2v99rzn.js:36:27 ``` 別の issue でも同じ系統のエラーが出ています。こちらは件数がかなり小さく、`keys=27 messages=26 rang

最初に切り分けたいのは、「本当に WorktreeRemove hook が失敗したのか」と「削除経路の都合でそう見えているだけか」です。今回の issue 群では、その2通りが混ざっています。 ひとつは [#82097](https://github.com/anthropics/claude-code/issues/82097) です。ここでは、`claude agents` の agent 削除で `WorktreeRemove hook failed` が出るものの、報告者の言葉では `~/.claude/hooks/worktree-remove.sh` はどの経路でも `0` を返しており、hook が直接壊れているわけではありません。報告では、`WorktreeCreate` で作られた worktree のセッション記録に `hookBased: true` が入り、`originalHeadCommit` がないため、CLI 側が worktree 状態を検証できず削除を拒んでいる、という説明になっています。つまり、見えているエラー文と実際の原因がずれている可能性があ

まず切り分けたいのは、`Read` が「全部読む」ときに途中まで返してくるケースなのか、`offset` や `limit` を指定したケースなのかです。今回の issue 群は同じ症状クラスタですが、挙動が少し違います。 ```text File content (84502 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file. ``` ここで引っかかるのは、文面だけ見ると「offset と limit を使え」と言われているのに、まさにその `offset` / `limit` 指定で失敗している点です。issue の報告では、2.1.145 で導入された「whole-file read を PARTIAL view で返す」改善は、あくまで `offset` / `li

まず、自分のケースかどうかを切り分けます。この症状は、Claude Code の実行中に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文字列が出て、`keys=` と `messages=` の数が一致していない形で報告されています。今回寄せられた 2 件の issue はどちらも未解決で、片方はセキュリティ監査の依頼中、もう片方は Claude Opus 5 の挙動変化を訴える内容でした。報告された場面は違いますが、出ているエラー本体は同じです。参照できる issue は [#90610](https://github.com/anthropics/claude-code/issues/90610) と [#90514](https://github.com/anthropics/claude-code/issues/90514) です。 症状の出方は、少なくとも issue 上ではかなり似ています。たとえば #90610 では、ローカルで動かしている Gitea の安全性確

このエラー名がそのまま出ているなら、少なくとも「Claude Code のセッション内部で、保持しているメッセージ数とキー数がずれた」状態に遭遇している可能性があります。今回見ている issue では、`itemKeys/messages length desync` が複数報告されていて、しかも症状の出方が少し違います。 たとえば [#90480](https://github.com/anthropics/claude-code/issues/90480) では、リファクタリング用の orchestrator と subagent を使っている途中で safeguard penalty が出たと報告されています。本文では「理由が不明だった」「Fable5 が自分で refactoring plan を組んだ」と書かれていました。 つまり、少なくとも issue 群を見る限りでは、これは単なる表示崩れではなく、複数の会話要素を持つセッションで内部状態が食い違ったときに現れているように見えます。とはいえ、原因までは断定できません。報告された内容だけでは、Claude Code 側のバグ

まず、このエラーが自分のケースかどうかを切り分けるなら、Claude Code の画面やログに次の文言が出ているかを見ます。 `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` 今回集めた issue は 2 件で、どちらも同じ症状クラスタに入っていました。1 件は [#87704](https://github.com/anthropics/claude-code/issues/87704) で、もう 1 件は [#86637](https://github.com/anthropics/claude-code/issues/86637) です。どちらの報告でも、エラー本体はほぼ同じ形で出ています。たとえば #87704 には次のようにあります。 ```json 報告されたエラー: TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=270 messages=269 range=[237

この症状は、Claude Code の画面側で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回集まっている issue は [#90375](https://github.com/anthropics/claude-code/issues/90375)、[#90360](https://github.com/anthropics/claude-code/issues/90360)、[#90339](https://github.com/anthropics/claude-code/issues/90339)、[#90260](https://github.com/anthropics/claude-code/issues/90260) の 4 件で、いずれも open のままで、少なくともこの範囲では解決済み報告はありません。 まず、このエラーは 4 件とも同じ文言です。 ```text TelemetrySafeError: VirtualMessageLi

この症状は、少なくとも issue 上では 2 件とも同じエラー文字列にぶつかっています。[#90073](https://github.com/anthropics/claude-code/issues/90073) と [#89917](https://github.com/anthropics/claude-code/issues/89917) のどちらも、報告されたエラーとして `Ptn: Insufficient scope: required "https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/drive.resource https://www.googleapis.com/auth/drive` が挙がっていました。 ただし、この 2 件の issue だけでは、Claude Code 側のどの処理でこのエラーが起きたのか、またどう直したのかまでは分かりません。少なくとも現時点では「Google

この症状は、少なくとも今回渡された issue では 2 つの顔を持っています。ひとつは、`--help` を付けたつもりのコマンドが実行されてしまったケース、もうひとつは、小さなファイルを読んでいる途中で CLI が長時間止まり、最後に `Request timed out.` を伴って落ちるケースです。どちらも共通して、表に出るのは `The socket connection was closed unexpectedly. For more information, pass \`verbose: true\` in the second argument to fetch()` というエラーです。 まず、自分のケースがどちらに近いかを切り分けます。 `--help` を付けたのに「説明だけ表示される」はずのコマンドが実際に動いてしまったなら、[#61285](https://github.com/anthropics/claude-code/issues/61285) が近いです。報告では `sfltool resetbtm --help` を実行したところ、`--help`

この症状は、少なくとも GitHub 上では 2 件まとまっていました。ひとつは Snapdragon X 環境での報告、もうひとつは Windows 11 Home の低スペック環境で、アップデート後に Cowork guest が毎回失敗するという報告です。どちらも同じエラー文言です。検索するなら `VM connection timeout after 60 seconds` で十分です。 筆者の環境で確認できた一次情報は、以下だけです。この記事で書けるのは、これ以上でもこれ以下でもありません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-08-22T08:50:32+09:00 ``` このため、現時点では「特定 OS 固有の不具合」「特定の更新後に増えた不具合」「低スペックや Snapdragon 系の環境で VM まわりが失敗している可能性」は疑えますが、断定はできません。少なくとも、報告済みの 2 件はどちらも「VM