#claudehowto

228 件の記事

Base64 decoding failed が出るときに見るところ
Base64 decoding failed が出るときに見るところ
まず、この症状に当てはまるかを切り分けます。今回の issue では、Claude Opus 4.6 で最近の更新以降に精度と信頼性が落ちたという報告が 2 件あり、その中に Gmail MCP 経由でメール添付を送るときに base64 文字列が壊れ、`Base64 decoding failed` になる、という内容が含まれていました。報告は [#96178](https://github.com/anthropics/claude-code/issues/96178) と [#96179](https://github.com/anthropics/claude-code/issues/96179) です。 この issue で確認できるのは、少なくとも次の 2 つです。ひとつは日付の取り違えで、2026 年 9 月の文面なのに 2025 年の日付を出したこと。もうひとつは base64 の再現文字列が壊れ、`Base64 decoding failed` に至ることです。つまり、単なる添付ファイル処理の失敗というより、モデルの出力自体が途中で崩れている可能性があります。現時点で
papoo.work
`Auto-update failed · Run claude doctor` が繰り返し出るときに見るところ
`Auto-update failed · Run claude doctor` が繰り返し出るときに見るところ
この症状でまず切り分けたいのは、本当に更新に失敗しているのか、それとも更新がないのに同じ通知だけが出続けているのかです。報告されている #96038 では、Wi‑Fi を切っただけで `Auto-update failed · Run claude doctor` が繰り返し表示され、しかも「更新がないのに」起きていると書かれています。つまり、少なくともこの issue では、実際の更新作業そのものというより、ネットワーク断をきっかけにした通知の再発が問題になっています。[#96038](https://github.com/anthropics/claude-code/issues/96038) 同じ `Auto-update failed · Run claude doctor` という表示でも、#78650 のほうは少し様子が違います。こちらは macOS の深いスリープからの復帰後に、複数の Claude Code セッションがほぼ同時に segfault で落ちたという報告で、本文では Bun の GC と socket finalizer、`SIGSEGV
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときにまず見ること
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときにまず見ること
この症状は、Claude Code の内部エラーとして `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回確認できた issue は 2 件で、どちらも open のままで、解決済みはありません。少なくとも提供された材料だけを見る限り、「これを入れれば直る」という確立した手順はまだありません。 自分のケースかどうかを見分けるなら、まずエラー文の形を確認します。今回の issue では、どちらも同じ系統の文言が出ています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=562 messages=558 range=[502,558)) at Ta0 (B:/~BUN/root/cli:23248:33899) at Rig (B:/~BUN/root/cli:23248:26870) ``` 別の報告では、値が少し違いますが、同じく `ite
papoo.work
`Connection refused — a firewall or proxy may be blocking it` が出るときに、まず確認したいこと
`Connection refused — a firewall or proxy may be blocking it` が出るときに、まず確認したいこと
この症状は、少なくとも報告上は 2 つの顔があります。ひとつは、毎回のコマンドで API への接続が失敗し、`Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)` を 10 回試行しても抜けられないケースです。もうひとつは、サブエージェントのストリームが途中で静かに止まり、`Agent stalled: no progress for 600s (stream watchdog did not recover)` で落ちるケースです。前者は [#93041](https://github.com/anthropics/claude-code/issues/93041)、後者は [#87987](https://github.com/anthropics/claude-code/issues/87987) にまとまっています。 自分のケースかどうかを切り分けるなら、まず見るべきなのは「Claude Code から API に出る通信だけが失敗しているのか」です。[#93041](h
papoo.work
`API Error: Sonnet 5 can't help with this` が出るときに見えていること
`API Error: Sonnet 5 can't help with this` が出るときに見えていること
この症状は、Claude Code が作業を始めた直後に `API Error: Sonnet 5 can't help with this` で止まり、しかも内容と関係なさそうな分類が付くケースとして報告されています。手元で確認できた issue は 2 件で、どちらも「本来の用途なのに止められた」という筋です。 まず、自分のケースかどうかを見分けるなら、Claude Code が何かを読んだり実行したりしたあとに、この文言だけを返して中断していないかを見ます。報告されている例では、ソフトウェア開発の途中で突然止まりました。`[bio]` のような詳細が付いていた例もありますが、少なくとも issue 報告上は、扱っていた内容と分類が一致していませんでした。これが [#87992](https://github.com/anthropics/claude-code/issues/87992) です。 もう 1 件の [#94875](https://github.com/anthropics/claude-code/issues/94875) では、USPTO の API キーを使っ
papoo.work
Authorization failed が出る Claude in Chrome の OAuth 失敗
Authorization failed が出る Claude in Chrome の OAuth 失敗
Claude Code から Claude in Chrome 拡張を使おうとして、`claude.ai/oauth/authorize` まで進んだのに、Authorize を押した直後に `Authorization failed` で止まる。今回の issue 群は、まさにその症状に当てはまります。 報告されているのは、Claude in Chrome extension の OAuth authorization が、認可画面で Authorize を押した直後に `Authorization failed — This isn't working right now` になる、というものです。#69051 では、拡張機能をインストールし、Claude Code 側で Claude in Chrome connector を有効にし、ブラウザで認可しても失敗する手順がそのまま書かれています。#95958 でも、別環境で同じ失敗が再現したとされています。参照できる issue は [#69051](https://github.com/anthropics/claude-code
papoo.work
`exit code 5` が出るとき、`/usage` が空振りすることがある
`exit code 5` が出るとき、`/usage` が空振りすることがある
`claude -p "/usage" --output-format json` を投げた直後に `exit code 5` で落ちる、あるいは `is_error:false` の包みだけ返って `result` がない、という症状が [#87983](https://github.com/anthropics/claude-code/issues/87983) で報告されています。報告者の環境では、長い print-mode 実行のあとに間隔をおかず起きていました。しかも 3 回の観測のうち 2 回は `exit code 5`、1 回はエラーヘッダのようなものがありつつ結果本体が欠ける形だったとされています。 手元で確認できる一次情報は、環境メモだけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-23T08:51:27+09:00 ``` この時点では、こちらで同じ不具合を再現するところまではできていません。なの
papoo.work
`Remote Control Initialization failed` が出るとき、まず見るべき分岐
`Remote Control Initialization failed` が出るとき、まず見るべき分岐
このエラーは、少なくとも今回の issue 群では 2 つの経路で出ています。ひとつは、`ANTHROPIC_API_KEY` が process 環境に残っているケースです。もうひとつは、Claude Desktop アプリ内の interactive session で `/remote-control` を実行したときに、毎回 `Remote Control Initialization failed` になるケースです。前者は [#81625](https://github.com/anthropics/claude-code/issues/81625)、後者は [#91325](https://github.com/anthropics/claude-code/issues/91325) にまとまっています。 切り分けの最初の一手は、今のセッションが何の認証状態で動いているか、そしてどこから起動しているかを見ることです。`/status` で Max が見えていても、`ANTHROPIC_API_KEY` が環境変数に入っていると Remote Control 初期化に失敗し
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"output_config.effort 'xhigh' is not supported when thinking is disabled on this model. Use effort 'high' or below, or enable thinking."}} が出たときに見る点
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"output_config.effort 'xhigh' is not supported when thinking is disabled on this model. Use effort 'high' or below, or enable thinking."}} が出たときに見る点
このエラーが出ているなら、少なくとも issue 上では「`effort` が `xhigh` のときに、thinking が無効なサブリクエストが走ると 400 になる」ケースが報告されています。対象になっているのは [#81627](https://github.com/anthropics/claude-code/issues/81627) で、同じ文言を含む別件として [#90721](https://github.com/anthropics/claude-code/issues/90721) もあります。 まず切り分けたいのは、単に会話が失敗しているのか、それとも WebSearch のような一部の機能だけが落ちているのか、という点です。#81627 では main の会話ループは `xhigh` でも動く一方、`WebSearch` だけが即座に失敗し、`WebFetch` は影響を受けないと報告されています。つまり、同じ `xhigh` でも「全部ダメ」ではなく「特定の内部リクエストだけダメ」という見え方になりえます。 issue の再現手順として書かれているのは、`~
papoo.work
`AxiosError: Request failed with status code 400
`AxiosError: Request failed with status code 400
at bo (/` が出たとき、まず `/context` の表示崩れを疑う 同じ `AxiosError: Request failed with status code 400` でも、今回集まっている issue は少し毛色が違います。報告されているのは、CLI の `400` そのものというより、画面の再描画や表示崩れに引きずられて見えているケースです。 ひとつは [#72900](https://github.com/anthropics/claude-code/issues/72900) で、狭い端末幅の `/context` 出力に長い skills 一覧が重なると、User skills セクションの項目が重複して表示されるという報告でした。もうひとつは [#60595](https://github.com/anthropics/claude-code/issues/60595) で、`<thinking></thinking>` の外に reasoning data が出てしまう症状として報告されています。どちらも、報告上は同じ `AxiosError: Reque
papoo.work
`Permission for this action was denied by the Claude Code auto mode classifier` が出るのに、実際は通っていることがある
`Permission for this action was denied by the Claude Code auto mode classifier` が出るのに、実際は通っていることがある
この症状は、Claude Code が操作を拒否したように見せながら、後で確認すると実際には処理が進んでいた、という形で報告されています。特に [#87831](https://github.com/anthropics/claude-code/issues/87831) では、`gh pr merge` を含む一括処理でその挙動が繰り返し起きたとされています。報告者は、`gh pr view --json state,mergedAt` を見るとマージ済みになっていたケースがあった一方、別の大きなバッチでは本当に実行されていなかったケースもあったと書いています。つまり、このエラー文だけでは「止まった」のか「止まったように見えただけで実行された」のかを判別できません。 まず自分のケースかどうかを切り分けるなら、エラーが出た直後に対象の状態を別コマンドで見に行く必要があります。`gh pr merge` を含む作業なら、少なくとも `gh pr view --json state,mergedAt` のように結果を確認して、実際に反映済みかどうかを確かめる、というのが issue から読
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — 画面の件数がずれて落ちるときに見えているもの
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — 画面の件数がずれて落ちるときに見えているもの
この症状は、Claude Code 側で `VirtualMessageList: itemKeys/messages length desync` が記録されているケースです。報告されている値は、`keys=45 messages=44`、`keys=359 messages=358`、`keys=149 messages=148` のように、1 件だけ数がずれている形でした。いずれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という同じ系統のエラーにまとまっています。参照できた issue は [#95707](https://github.com/anthropics/claude-code/issues/95707)、[#95662](https://github.com/anthropics/claude-code/issues/95662)、[#95586](https://github.com/anthropics/claude-code/issues/95586)
papoo.work
`--resume requires a valid session ID or session title when used with --print.` が出るときに確認したいこと
`--resume requires a valid session ID or session title when used with --print.` が出るときに確認したいこと
このエラーは、`--resume` に渡した値が Claude Code 側で「有効な session ID でも session title でもない」と判断されたときに出ます。今回の症状クラスタでは、少なくとも 2 つの別ルートが issue として報告されています。 ひとつは [#61058](https://github.com/anthropics/claude-code/issues/61058) で、`claude -p --output-format stream-json --input-format stream-json` で生成したセッションが `sessions-index.json` に登録されず、`--resume <title>` や対話的な `--resume` ピッカーから見えないという報告です。もうひとつは [#91268](https://github.com/anthropics/claude-code/issues/91268) で、セッション管理ツールが返す `local_...` 形式の ID をそのまま `claude --resume
papoo.work
File is in a directory that is denied by your permission set で止まるときに、まず見るところ
File is in a directory that is denied by your permission set で止まるときに、まず見るところ
このエラーは、読もうとしたファイルが `permissions.deny` の対象に入っているときに出ます。少なくとも issue [#73380](https://github.com/anthropics/claude-code/issues/73380) では、`Read(/*.xcconfig)` や `Read(/APIConstants.swift)` のような deny ルールと、`PreToolUse` hook を組み合わせてメインエージェントの読み取りを止める設定が報告されています。 ただし、同じ issue では少し気になる点も出ています。`Task` / `Agent` ツールで起動したサブエージェントが、ある時点では本来 denied のはずのファイル内容を返してしまい、その後の再テストでは同じ設定・同じファイルでも正しくブロックされた、と書かれています。つまり、少なくとも報告ベースでは「deny ルールが効いていない」と断言する前に、「どのエージェント経由で読みに行ったか」を切り分けたほうがよさそうです。 手元で確認できた環境情報はこれだけです。 `
papoo.work
`Error: NON-FATAL: Lock acquisition failed for /Users/alexsonne/.local/share/claude/versions/2.1.119` が出るときにまず見るところ
`Error: NON-FATAL: Lock acquisition failed for /Users/alexsonne/.local/share/claude/versions/2.1.119` が出るときにまず見るところ
このエラーは、Issue 上では少なくとも 2 件まとまって報告されています。該当するのは [#52724](https://github.com/anthropics/claude-code/issues/52724) と [#54055](https://github.com/anthropics/claude-code/issues/54055) です。どちらも `Error: NON-FATAL: Lock acquisition failed for /Users/.../.local/share/claude/versions/2.1.119 (expected in multi-process scenarios)` という文言を含んでいます。 ただし、Issue だけでは「このロック失敗そのもの」が致命的な原因なのか、それとも別の不具合に付随して表示されているのかは切り分けきれません。少なくともコメント欄では、別経路の対処として `~/.claude/keybindings.json` の確認が有効だった例が 1 件出ています。Enter で保存したつもりが保存されず、
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
この症状に当てはまるかどうかは、まず表示されているエラー文字列で切り分けられます。今回集まっている issue では、どちらも同じ系統のエラーとして `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が報告されています。ひとつは `keys=1313 messages=1312 range=[1284,1313)`、もうひとつは `keys=100 messages=99 range=[69,100)` で、`itemKeys` と `messages` の数が 1 件ずれていました。 報告元は [#95562](https://github.com/anthropics/claude-code/issues/95562) と [#95325](https://github.com/anthropics/claude-code/issues/95325) です。 この2件だけを見る限り、起きているのは「途中のメッセージ一覧を扱う処理で、キーの数とメッセージ本体の数が一致していない」状態です
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の切り分けメモ
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の切り分けメモ
この症状は、issue 上では同じエラー文字列として 2 件まとまっています。どちらも、表示されているのは `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=429 messages=426 range=[393,426))` で、スタックトレースも `B:/~BUN/root/cli` 配下から出ています。報告は [#95537](https://github.com/anthropics/claude-code/issues/95537) と [#95518](https://github.com/anthropics/claude-code/issues/95518) です。 まず、自分のケースかどうかはエラー文字列で見分けるのが早いです。Issue に出ている文字列は次のとおりでした。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=429 mess
papoo.work
Remote Control failed to connect: Remote Control connect timed out が出るときに見ておくこと
Remote Control failed to connect: Remote Control connect timed out が出るときに見ておくこと
この症状は、少なくとも報告上は「一度つながったはずの Remote Control が、再接続で失敗する」かたちで出ています。該当する issue は [#95609](https://github.com/anthropics/claude-code/issues/95609) と [#87720](https://github.com/anthropics/claude-code/issues/87720) です。どちらも、`Remote Control failed to connect: Remote Control connect timed out` で止まる、あるいは `connecting` のまま進まない、という流れが書かれています。 まず切り分けたいのは、「そのセッションだけがおかしいのか」「Remote Control 自体が環境全体で不安定なのか」です。#95609 では、同じアカウントでも別のセッションは claude.ai/code の Web では見えており、モバイル側だけ `連結 해제됨` 相当の状態に見えていました。つまり、アカウント全体の認証不能とい
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときに見えていたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときに見えていたこと
この症状は、Claude Code の画面内で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回確認できた issue は 2 件だけで、どちらも open のままでした。該当するのは [#92184](https://github.com/anthropics/claude-code/issues/92184) と [#95493](https://github.com/anthropics/claude-code/issues/95493) です。 読者がまず確認したいのは、自分の表示しているエラー文が同じかどうかだと思います。少なくとも issue 側では、次の形が報告されています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=214 messages=213 range=[147,214)) at N$t (B:/~BUN/ro
papoo.work
`disabled after repeated failures · restart to retry` が出るときに見えていること
`disabled after repeated failures · restart to retry` が出るときに見えていること
この症状は、Claude Code の Remote Control が起動時やセッション中の短い失敗をきっかけに、再試行できないまま無効化されるケースとして報告されています。少なくとも issue では、失敗後に自動で復帰しない、あるいは復帰の手がかりが利用者側から見えない、という点が共通しています。 自分のケースかどうかを最初に切り分けるなら、次の2つに当てはまるかを見ます。ひとつは、起動直後の transient な通信失敗や認証まわりの失敗のあとに Remote Control が戻らないこと。もうひとつは、背景実行や分離されたセッションでは、その失敗が表に出てきにくいことです。 手元で実際に取れている出力は環境情報だけでした。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-20T08:51:48+09:00 ``` なので、この段階では「特定の OS だけで起きる」とは言えません。issue だけを見る限り、少なくと
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"自分のツール定義が JSON Schema 2020-12 に通っていないときに出る Claude Code の 400
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"自分のツール定義が JSON Schema 2020-12 に通っていないときに出る Claude Code の 400
このエラーは、Claude Code 側がツール定義の `input_schema` を Anthropic API に送ったとき、JSON schema が受け付けられずに 400 で返ってきたケースとして報告されています。手元で確認できる issue は 2 件で、どちらも同じ系統の文言でした。 まず切り分けたいのは、Claude Code 本体の一般的な通信失敗ではなく、ツール定義のスキーマで落ちているかどうかです。今回の症状クラスタに含まれる実例では、エラーメッセージの中心が一貫して `custom.input_schema` になっています。`use tool` の実行時に 400 になる、という報告もありました。#86664 の環境情報は次のとおりです。 ```text Platform: darwin Terminal: iTerm.app Version: 2.1.232 Feedback ID: 0a5623a4-408d-47fb-afb1-0f3fd41d124a ``` 報告本文に含まれていたエラー断片も、そのまま載せておきます。 ```json ``` ここか
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"messages.73.content.17.image.source.base64.data: At least one of the image dimensi… が出るときに見ておくこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"messages.73.content.17.image.source.base64.data: At least one of the image dimensi… が出るときに見ておくこと
この症状は、少なくとも 2 件の issue で同じ系統として報告されています。手元で確認できる範囲では、どちらも画像を含むリクエストで `Error: 400 {"type":"error","error":{"type":"invalid_request_error"...` が返っており、文言の中心は「画像サイズが many-image requests の上限を超えた」というものです。 手元の実測で確認できるのは、検証環境が Linux 上の Python 3.8.13 であることだけです。今回の症状に対して、こちらで再現手順や回避策までは実測できていません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-20T08:51:39+09:00 ``` なので、現時点で言えるのは「画像を含むリクエストで、少なくとも一部の画像が many-image requests の許容サイズを超えたときにこの 400 が返る」というと
papoo.work
authentication failed が出るときにまず見るところ
authentication failed が出るときにまず見るところ
`authentication failed` という表示だけでは原因は絞れませんが、今回の issue 群で確認できるのは、少なくとも 2 つの別系統があることです。ひとつはリモート制御のセッション作成で 401 が返るケース、もうひとつは Windows 上での操作中に別の経路から制御が抜けるケースです。後者は別の症状ですが、同じく認証や制御の前提が崩れているときに起きています。 まず、自分の症状がどちらに近いかを切り分けたほうが早いです。`/remote-control` を開いた瞬間に「Session creation failed — see debug log.」となるなら、[#78580](https://github.com/anthropics/claude-code/issues/78580) の系統です。そこでは `code-session` 作成エンドポイントが 401 を返し、`claude auth logout` と `claude auth login` をやり直しても失敗し続けたと報告されています。issue の本文では「stale/incorrect
papoo.work
auto mode is unavailable for your plan が出るときにまず見ること
auto mode is unavailable for your plan が出るときにまず見ること
この症状は、`auto mode is unavailable for your plan` という文言がそのまま出るケースです。今回の報告では、Claude Max で `Shift+Tab` から Plan mode に入ろうとしたとき、または `/plan` を打ったときに同じエラーが出ています。該当 issue は [#44708](https://github.com/anthropics/claude-code/issues/44708) です。 同じ文字列でも、報告内容を見る限り少なくとも 2 つのパターンがあります。ひとつは Max subscription で Plan mode を選んだのに、このエラーが出るケースです。もうひとつは Pro plan で Claude.ai OAuth でログインしているのに、Auto mode が利用不可と表示されるケースです。後者は [#66510](https://github.com/anthropics/claude-code/issues/66510) にあります。 まず切り分けたいのは、今見えているのが Plan mo
papoo.work
MCP server providing this tool may be unresponsive, crashed, or not running. が出るときに見えているもの
MCP server providing this tool may be unresponsive, crashed, or not running. が出るときに見えているもの
この症状は、少なくとも今回渡された 2 件の issue では、Claude Desktop 側の MCP クライアントが出しているメッセージとして報告されています。サーバーが本当に落ちていると断定できる材料はありません。むしろ、[#83908](https://github.com/anthropics/claude-code/issues/83908) では「チャットを切り替えた瞬間に tool/call が破棄され、サーバーには何も書き込まれない」と説明されています。つまり、見えているエラー文のわりに、原因がサーバー側とは限らない、というのが出発点です。 今回の私の環境では、再現手順やログは取得していません。手元で実際に確認できたのは環境情報だけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-19T08:51:24+09:00 ``` なので、ここでは「何を疑うべきか」を issue の報告ベースで絞ります
papoo.work
`Error: 502 <html><head><title>502 Bad Gateway</title></head><body><center><h1>502 Bad Gateway</h1></center><hr><center>cloudflare</center></body></html>` が返るときに見えているもの
`Error: 502 <html><head><title>502 Bad Gateway</title></head><body><center><h1>502 Bad Gateway</h1></center><hr><center>cloudflare</center></body></html>` が返るときに見えているもの
この症状は、少なくとも GitHub issue では 2 件とも同じ形で報告されています。どちらも Claude Code の実行中に `Error: 502` と Cloudflare の `502 Bad Gateway` HTML が返っており、スタックトレースには `generate` と `makeRequest` が出ています。該当 issue は [#67734](https://github.com/anthropics/claude-code/issues/67734) と [#66186](https://github.com/anthropics/claude-code/issues/66186) です。 まず切り分けたいのは、手元の失敗が「Claude Code からのリクエストが途中で 502 に落ちている」ケースかどうかです。提示された 2 件はいずれも、アプリ固有のメッセージではなく Cloudflare の HTML がそのまま返っています。報告内容からは、少なくとも Claude Code 側の処理が HTTP 502 を受け取って失敗していることは
papoo.work
`Error: 401 {"type":"error","error":{"type":"authentication_e` が出るときに見えていたこと
`Error: 401 {"type":"error","error":{"type":"authentication_e` が出るときに見えていたこと
まず、この件は「認証情報が無効です」という 401 で、報告されている文面はどの issue でもかなり似ています。今回の症状クラスタでは、代表 issue のエラー文が次の形でした。 ```text Error: 401 {"type":"error","error":{"type":"authentication_error","message":"Invalid authentication credentials"},"request_id":"req_011CcxEXkC4V93twN7Wd7Be7"} ``` 同じクラスタに含まれている #79249 と #79242 でも、どちらもこの 401 が出ています。`request_id` はそれぞれ違いますが、返ってきたメッセージ自体は同じです。 #79249: [#79249](https://github.com/anthropics/claude-code/issues/79249) #79242: [#79242](https://github.com/anthropics/claude-code/issues/792
papoo.work
Remote Control failed が出るときに見えていたこと
Remote Control failed が出るときに見えていたこと
`Remote Control failed` という同じ文言でも、issue を読む限り中身が少し違います。少なくとも今回集めた報告では、どちらも「接続しようとした瞬間に失敗する」点は共通していますが、片方は `/bridge` エンドポイントでの 401、もう片方は `Remote Control server rejected the request (HTTP 403)` でした。 自分のケースがどちらに近いかは、まずこの出方で切り分けられます。`[#78453](https://github.com/anthropics/claude-code/issues/78453)` では、セッション作成後の remote control 接続が `401 Authentication failed at /bridge endpoint` になっています。報告文には、完全にサインアウトして入り直しても直らなかったとあります。`[#92760](https://github.com/anthropics/claude-code/issues/92760)` では、Claude Desk
papoo.work
`Error: Tool Glob not found
`Error: Tool Glob not found
at URK (/$bunfs/root/src/entr` が出るときに、まず見るべきこと この症状は、Claude Code の issue 報告では少なくとも 2 件確認できました。どちらも報告されているエラーの形は同じで、`Error: Tool Glob not found` から始まるスタックトレースが付いています。該当するのは [#67458](https://github.com/anthropics/claude-code/issues/67458) と [#67213](https://github.com/anthropics/claude-code/issues/67213) です。 ただし、今回渡された情報の範囲では、これが「何をすれば直るか」までは確定できません。代表 issue のコメントも、いずれも自動で close / lock された旨だけで、解決手順は載っていませんでした。なので、ここでは「どんなときにこのエラーに当たりやすいか」と「手元で確認できた事実」だけに絞ります。 `#67458` では、spec ファイルを解析させた流れの中で拒否が起きて
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず切り分けたいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず切り分けたいこと
この症状は、Claude Code の issue 群で同じエラー文字列が繰り返し出ているものです。代表的には [#95229](https://github.com/anthropics/claude-code/issues/95229)、[#95224](https://github.com/anthropics/claude-code/issues/95224)、[#95210](https://github.com/anthropics/claude-code/issues/95210)、[#95109](https://github.com/anthropics/claude-code/issues/95109) で、いずれも報告されたエラーとして `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が付いています。 ただし、少なくとも今回渡された issue 群だけを見る限り、解決済みの報告はなく、根本原因も確定していません。 まず見るべきなのは、「会話内容の表示・保持がおかしい
papoo.work
ERR_CONNECTION_CLOSED が出たときに、まず見分けたいこと
ERR_CONNECTION_CLOSED が出たときに、まず見分けたいこと
`ERR_CONNECTION_CLOSED` という文字列だけを見ると、ひとつの原因に見えてしまいます。ですが、今回の issue 群を見る限り、少なくとも二つの出方があります。 ひとつは、Cowork の macOS Desktop でチャット用の webview がネットワークを失って、そのまま戻らなくなるケースです。報告では、エージェント側の処理は続いているのに、画面側だけが壊れたままになり、送ったメッセージが灰色の「ghost bubble」として残るとされています。AskUserQuestion も描画されず、自動で拒否されたように見える、と書かれています。これは [#65382](https://github.com/anthropics/claude-code/issues/65382) の報告です。 もうひとつは、Windows の auto-updater で、Electron のネットワーク層だけが `ERR_CONNECTION_CLOSED` を返すケースです。報告では、`curl` と `node https.get()` では同じ更新先に届くのに、Elec
papoo.work
`The advisor tool is unavailable. Do not try to use it again.` が出るとき、まず疑うべきこと
`The advisor tool is unavailable. Do not try to use it again.` が出るとき、まず疑うべきこと
この症状は、少なくとも [#66784](https://github.com/anthropics/claude-code/issues/66784) と [#76139](https://github.com/anthropics/claude-code/issues/76139) で報告されています。どちらも、advisor を使おうとした場面で同じ文言が返ってきます。 手元で確認できた検証環境は次の通りです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-18T08:51:10+09:00 ``` まず切り分けたいのは、通常の advisor 不調ではなく、特定のモデル組み合わせで advisor が使えなくなっているケースかどうかです。 手元の資料から言えるのはここまでです。少なくとも、このエラーが出たら「advisor 自体の一時障害」と決め打ちせず、まずはメインモデル名に `[1m]` のような suffix を
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときにまず確認すること
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときにまず確認すること
このエラーは、今回渡された issue 報告では [#94645](https://github.com/anthropics/claude-code/issues/94645) と [#94531](https://github.com/anthropics/claude-code/issues/94531) の 2 件で確認できました。どちらも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で始まり、`keys` と `messages` の件数が 1 つずれていました。 まず、自分のケースかどうかを見るなら、エラー文に次の形が入っているかを確認します。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=164 messages=163 range=[132,164)) at R7t (B:/~BUN/root/chunk-te7sk2cq.js:36:2985
papoo.work
`Claude Code returned an error result: No conversation found with session ID: <session-id>` が出るときに、まず見るところ
`Claude Code returned an error result: No conversation found with session ID: <session-id>` が出るときに、まず見るところ
このエラーが出るのは、VS Code の Claude Code 拡張でセッションを開き直そうとしたときです。今回の issue では、少なくとも [#79118](https://github.com/anthropics/claude-code/issues/79118) と [#79122](https://github.com/anthropics/claude-code/issues/79122) の 2 件で同じ文言が報告されています。 最初に確認したいのは、単なる表示不具合ではなく、セッションファイル側に会話本文が残っていないケースかどうかです。[#79118](https://github.com/anthropics/claude-code/issues/79118) では、`~/.claude/projects/<project-slug>/<session-id>.jsonl` 自体は存在していたものの、実際に入っていたのは会話本文ではなく、次の 2 行だけだったと報告されています。 ```json {"type":"ai-title","aiTitle":"Re
papoo.work
`Session creation failed — see debug log` が出るときに、まず切り分けたいこと
`Session creation failed — see debug log` が出るときに、まず切り分けたいこと
このエラーが出たとしても、同じ見え方で中身が違うことがあります。今回の issue 報告では、少なくとも二つのパターンがありました。ひとつは Remote Control のセッション登録が失敗するケース、もうひとつは `/remote-control` をその場で打ったときに最初の一回だけ無言で失敗するケースです。 手元で実際に確認できた環境情報はこれだけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-16T08:51:20+09:00 ``` この情報だけでは、今回の症状が issue のどちらと一致するかは断定できません。ただ、もしあなたの環境で次のどれかに当てはまるなら、報告されているクラスタにかなり近いです。 Docker やコンテナの中で Claude Code を動かしていて、Remote Control の登録だけが失敗する `/remote-control` を最初に打ったときだけ何も起きず、二回目で通
papoo.work
`MaxFileReadTokenExceededError: [REDACTED] content (34762 tok` が出るときに見えていたこと
`MaxFileReadTokenExceededError: [REDACTED] content (34762 tok` が出るときに見えていたこと
この症状に当てはまるのは、エラー文の中に `MaxFileReadTokenExceededError: [REDACTED] content (34762 tokens) exceeds maximum allowed tokens (25000)` が出ていて、しかも Claude Code 側が「長すぎる内容を一度に読もうとして失敗した」ように見えるケースです。今回参照できた issue は、まったく別の状況に見える報告も含めて 2 件ありましたが、どちらも同じエラー文字列が出ています。 1 件目は [#59827](https://github.com/anthropics/claude-code/issues/59827) で、`Goal function causes infinite loop when waiting for task completion` という報告でした。本文では、goal function が「タスク完了を待つ」場面で何度も同じ確認を繰り返し、結果として無限ループになったと書かれています。報告者は、goal evaluator が再評価を繰り返す
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools.11.model: 'claude-opus-4-8' cannot be used as an advisor when the request mo…"} が出るときに確認したいこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools.11.model: 'claude-opus-4-8' cannot be used as an advisor when the request mo…"} が出るときに確認したいこと
この症状は、Claude Code 側のリクエストで `advisor` として使われるモデルが、実行しようとしている request model と噛み合っていないときに出ています。今回集まっている issue では、メッセージの中身がかなりはっきりしています。 `[#66865](https://github.com/anthropics/claude-code/issues/66865)` では、`tools.10.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5'.` と出ています。`[#66940](https://github.com/anthropics/claude-code/issues/66940)` でも同じ構造で、`tools.11.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5'
papoo.work
ETIMEDOUT が出るときに、再接続が止まる場合と CLI が固まる場合
ETIMEDOUT が出るときに、再接続が止まる場合と CLI が固まる場合
この症状は、少なくとも 2 つの報告に分かれていました。ひとつは、スリープ解除後に Desktop App が再接続を 3 回試したあとで止まり、それ以上の自動再試行をしなくなるケースです。もうひとつは、headless Linux 上で `claude` のサブコマンドが `--version` を除いて固まり続けるケースです。どちらも、ユーザー側から見ると「応答が返らない」「つながらない」という形で見えますが、現れ方はかなり違います。 まず、スリープ復帰まわりの報告は [#78666](https://github.com/anthropics/claude-code/issues/78666) です。報告では、クライアント機が sleep/wake したあと、ネットワークがまだ戻っていないタイミングで Desktop App が transport dead を検知し、その後に自動再接続がちょうど 3 回、約 6 秒の間に走るとされています。3 回とも `host is offline` で失敗し、その後は `Auto-reconnect exhausted` になって自動では再
papoo.work
Application Error が出るときの Claude Code: Windows 11 Settings とデスクトップアプリで起きていたこと
Application Error が出るときの Claude Code: Windows 11 Settings とデスクトップアプリで起きていたこと
最初に切り分けたいのは、壊れているのが Claude 本体なのか、Windows 11 の設定画面なのかです。今回の issue では、少なくとも 2 つの別の見え方がありました。ひとつは Windows 11 の Settings アプリが落ちるケース、もうひとつは Claude desktop app が起動後しばらくして閉じ、その後は開けなくなるケースです。 前者は [#79893](https://github.com/anthropics/claude-code/issues/79893) にあり、イベントの内容として `SystemSettings.exe` が `SettingsHandlers_Startup.dll` で失敗しています。後者は [#85797](https://github.com/anthropics/claude-code/issues/85797) で、Claude desktop app 自体が数分後に閉じ、そのあと Windows に `"This app can't be opened."` と出る、という報告です。どちらも Windows
papoo.work
`Error: Streamable HTTP error: Error POSTing to endpoint: <html>` が出るときに見えていたもの
`Error: Streamable HTTP error: Error POSTing to endpoint: <html>` が出るときに見えていたもの
この症状は、少なくとも今回渡された issue 群では、Claude Code が POST 先の endpoint に対して返ってきた HTML の `502 Bad Gateway` をそのままエラーとして見せている場面でした。報告はどちらも同じ文字列を含んでいます。 該当 issue は [#87221](https://github.com/anthropics/claude-code/issues/87221) と [#86687](https://github.com/anthropics/claude-code/issues/86687) です。 まず切り分けたいのは、あなたの画面に出ているのが「Claude Code 側の操作ミス」ではなく、POST の先で `502 Bad Gateway` が返っているケースかどうかです。今回の報告では、エラーメッセージの中に次の HTML が含まれていました。 ```html <html> <head><title>502 Bad Gateway</title></head> <body> <center><h1>502 Bad
papoo.work
This site is not allowed due to safety restrictions が出て Shopee / Lazada Seller Center に入れないとき
This site is not allowed due to safety restrictions が出て Shopee / Lazada Seller Center に入れないとき
この症状は、Claude in Chrome の安全制限でサイト遷移が止められているケースです。少なくとも issue [#82218](https://github.com/anthropics/claude-code/issues/82218) では、Shopee Seller Center と Lazada Seller Center が restricted domain として扱われ、ページが開く前に次のエラーで止まると報告されています。 > This site is not allowed due to safety restrictions. 報告されている対象は、たとえば次の URL です。 `https://seller.shopee.co.id` `https://sellercenter.lazada.co.id` 同じプラットフォームでも、別の国の TLD も影響を受ける可能性があると issue には書かれていますが、どこまで広がっているかはこの報告だけでは断定できません。 自分のケースかどうかを見分ける一番手っ取り早い方法は、Claude in Chrome
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の desync に当たるときに見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の desync に当たるときに見るところ
この件は、少なくとも issue 上では `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という同じエラーでまとまっています。報告は 3 件あり、いずれも open のままで、解決済みは 0 件でした。なので、現時点では「既知の恒久的な解決策がある」とは言えません。 まず、自分のケースかどうかを切り分けるなら、エラー本文がこの形かを見ます。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=554 messages=553 range=[527,554)) at o8t (B:/~BUN/root/chunk-k298bv0z.js:36:28 ``` 同じ症状として確認できた報告は次の 3 件です。 重要なのは、少なくともこの 3 件だけを見る限り、問題の本体が「VirtualMessageList の itemKeys と messages の数がずれている」こと
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出るときに見えていること
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出るときに見えていること
この症状は、少なくとも issue 報告上では Claude Code の内部で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースとしてまとまっています。手元で確認できるのは、同じエラー文字列を含む 2 件の issue と、そこに付いた限定的なコメントだけです。現時点では、再現手順や恒久対応は issue 側でも確立していません。 まず、自分のケースかどうかを見分けるなら、エラー本文がこの文字列に一致するかを確認するのがいちばん確実です。少なくとも報告された 2 件では、`itemKeys/messages` の件数が一致していないことがログに出ています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=101 messages=100 range=[68,101)) at Tn_ (/$bunfs/root/src/entrypoints/cli
papoo.work
`Error: Tool bash not found
`Error: Tool bash not found
at _XK (/$bunfs/root/src/entr` が出たときに見ること まず自分のケースかどうかを切り分けるなら、症状はかなりはっきりしています。Claude Code の実行中に `Error: Tool bash not found` という文言が出て、その先に `at _XK (/$bunfs/root/src/entrypoints/cli.js:4390:15288)` のようなスタックトレースが続きます。今回集まっている issue は 2 件で、どちらも closed ですが、報告内容は別の困りごとで始まりつつ、共通してこのエラーが載っています。ひとつは weekly limit の消費が想定より速いという [#66124](https://github.com/anthropics/claude-code/issues/66124)、もうひとつは AskUserQuestion の Clarify で入力した文面がモデルに渡らないという [#66224](https://github.com/anthropics/claude-code/issues/662
papoo.work
ERR_CONNECTION_REFUSED で Claude Code の OAuth が止まるときに見るところ
ERR_CONNECTION_REFUSED で Claude Code の OAuth が止まるときに見るところ
まず、この症状に当てはまるかどうかはかなりはっきりしています。issue #66332 では、Android 端末から GitHub Codespaces を使っていると、Claude Code の OAuth が `localhost:PORT/callback` に飛び、その先に接続できず `ERR_CONNECTION_REFUSED` になると報告されています。`claude setup-token` でも同じ localhost リダイレクトで失敗した、と書かれています。別件の #70415 では、ブラウザベースの Codespace（`.github.dev`）で `CLAUDE_CODE_OAUTH_TOKEN` 環境変数が無視され、ログインメニューから Claude account を選ぶとやはり localhost の OAuth callback で `ERR_CONNECTION_REFUSED` になった、という報告でした。 つまり、少なくともこの 2 件で共通しているのは、「ブラウザから localhost に戻る認証経路が使えない環境で止まる」ことです。An
papoo.work
Claude Code process terminated by signal SIGILL が出るときの切り分け
Claude Code process terminated by signal SIGILL が出るときの切り分け
この症状は、Claude Code の起動時に `SIGILL` で落ちるケースです。手元で確認できた一次情報は Linux 環境の以下の出力だけで、Claude Code 自体の実行結果は取得できていません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-14T08:51:11+09:00 ``` GitHub Issue では、同じエラーが Intel Westmere 世代の CPU で報告されています。[#34481](https://github.com/anthropics/claude-code/issues/34481) と [#37065](https://github.com/anthropics/claude-code/issues/37065) のどちらも、VS Code 拡張機能側で ```text Error: Claude Code process terminated by signal SIG
papoo.work
`Plan9 mount failed: invalid argument` が出たら、まず Windows 更新後かどうかを見る
`Plan9 mount failed: invalid argument` が出たら、まず Windows 更新後かどうかを見る
Claude Code の Cowork で、ホスト側は成功しているのにゲスト側だけ Plan9 のマウントが全部失敗する症状が、Windows 更新の直後にまとまって出ています。報告されている issue は [#92984](https://github.com/anthropics/claude-code/issues/92984)、[#92958](https://github.com/anthropics/claude-code/issues/92958)、[#93283](https://github.com/anthropics/claude-code/issues/93283) です。 読者がいちばん気にするのは「自分のケースかどうか」だと思うので、先に切り分けます。issue で一致しているのは、Windows 11 上の Cowork で、VM は起動するのに Plan9 share の mount だけが落ちることです。ホスト側の attach は成功扱いでも、ゲスト側では `Plan9 mount failed: invalid argument` になり、その
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の文字列が出たら見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の文字列が出たら見るところ
この症状は、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)
papoo.work
`Tool result missing due to internal error` が出るときに見るべきこと
`Tool result missing due to internal error` が出るときに見るべきこと
このエラー文字列だけを見ても、同じ症状かどうかは少し分かれます。少なくとも今回の issue 群では、2 つの出方がありました。ひとつは Bash や Read の結果が 1 ターン遅れて返る、あるいは途中から消えるという報告で、[#63766](https://github.com/anthropics/claude-code/issues/63766) にあります。もうひとつは VS Code のパネル webview で AskUserQuestion が失敗し、ターミナルの TUI では動くという報告で、[#72624](https://github.com/anthropics/claude-code/issues/72624) です。 つまり、まず切り分けたいのは「ターミナルでも起きるのか」「VS Code のパネルだけなのか」です。`claude` を普通の端末で動かしたときに問題が出ないなら、[#72624](https://github.com/anthropics/claude-code/issues/72624) のように panel webview 側に寄った話
papoo.work
Failed to start Claude's workspace - RPC error -1: SDK version 2.1.260 not verified と [Unsupported Image] が同時に出るときに見る場所
Failed to start Claude's workspace - RPC error -1: SDK version 2.1.260 not verified と [Unsupported Image] が同時に出るときに見る場所
まず切り分けたいのは、この症状が Claude Desktop 全体の不調なのか、それとも Desktop 内の Code tab だけで起きているのか、です。今回の issue [#93696](https://github.com/anthropics/claude-code/issues/93696) と [#93693](https://github.com/anthropics/claude-code/issues/93693) では、どちらも「Claude Desktop on Windows」で画像を送ると `[Unsupported Image]` になり、さらに workspace の起動に `Failed to start Claude's workspace - RPC error -1: SDK version 2.1.260 not verified` が出る、と報告されています。 ここで重要なのは、コメントでこの workspace エラーが「Claude Desktop 固有ではなく、Claude Desktop アプリ内で動く Claude Code の
papoo.work
ENOTDIR が出るときに見るべき 2 つの壊れ方
ENOTDIR が出るときに見るべき 2 つの壊れ方
まず、この `ENOTDIR` は 1 つの症状に見えて、少なくとも issue 上では 2 つの壊れ方が報告されています。どちらも「ディレクトリとして扱うはずの場所が、そう扱えない」という点は共通ですが、起きる場所が違います。 ひとつは、デスクトップアプリでセッションを fork するときです。`~/.claude/projects/<project>` がシンボリックリンクになっている環境で、`LocalSessions.forkSession` の IPC ハンドラが `ENOTDIR` を投げ、UI 側でエラーが飲み込まれてしまう、という報告でした。結果として何も起きないか、親履歴のない空の新規セッションになるようです。これは [#90931](https://github.com/anthropics/claude-code/issues/90931) に書かれています。 もうひとつは Bash tool 側です。こちらはコマンドが走る前に落ちます。issue では、セッションディレクトリを `/proc/self/fd/N/` 経由で作ろうとして `ENOTDIR` になっ
papoo.work
`OAuth session expired and could not be refreshed` が出るときにまず確認したいこと
`OAuth session expired and could not be refreshed` が出るときにまず確認したいこと
この症状は、少なくとも issue [#81937](https://github.com/anthropics/claude-code/issues/81937) と [#93521](https://github.com/anthropics/claude-code/issues/93521) で報告されています。どちらも「OAuth のセッションが期限切れで、更新できない」という同じ文言に見えますが、出方が少し違います。 ```text Failed to authenticate: OAuth session expired and could not be refreshed ``` ```text Failed to authenticate. API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth access token has been revoked."},"request_id":null} ``` 一方 [#93521](https://gith
papoo.work
Claude Desktop で HTTP 503 が出るときに見えていたこと
Claude Desktop で HTTP 503 が出るときに見えていたこと
まず切り分けたいのは、「起動時や設定画面の読み込みで 503 が返っている」のか、それとも「一度サインインできたあと、裏側の認証や設定取得だけが失敗している」のかです。今回の issue では、その両方に近い報告がありました。 一方で [#93577](https://github.com/anthropics/claude-code/issues/93577) は、`app://localhost/setup-desktop-3p` を開くと常に「Unable to load configuration」になり、ログには次のように出ています。 ```text ``` この issue では、Claude-3p の profile cache は消しても改善せず、アプリは最新バージョンで、OAuth 側の `invalid_grant / session_stale_relogin` はフルログアウトと再ログインで解消済みでした。それでも 503 は残っています。コメントでは「Claude Code の issue には見えないので、必要なら新規 issue を」と案内されており、少な
papoo.work
`ERR_INVALID_ARG_TYPE` が出て Chrome / Brave の native host が落ちるときの切り分け
`ERR_INVALID_ARG_TYPE` が出て Chrome / Brave の native host が落ちるときの切り分け
最初に見ておきたいのは、これが Windows 系の issue に寄っているかどうかです。今回の報告はどちらも Windows 11 上で、Claude Code の Chrome 連携まわりの native host が起動直後に `ERR_INVALID_ARG_TYPE` で落ちる、という形でした。ひとつは [#57846](https://github.com/anthropics/claude-code/issues/57846)、もうひとつは [#76556](https://github.com/anthropics/claude-code/issues/76556) です。 この症状に当たっているかは、かなりはっきりしています。Claude Code の Chrome 連携を使った瞬間に、拡張機能が「接続されていない」扱いになる。あるいは native host 自体がすぐ死んで、`ERR_INVALID_ARG_TYPE` が見える。どちらも issue 側では Windows 上の再現例でした。少なくとも、今回集められた報告からは macOS や Linux での
papoo.work
`Failed to start Claude's workspace — Download failed. Check your internet connection and try again.` が出るときに見る場所
`Failed to start Claude's workspace — Download failed. Check your internet connection and try again.` が出るときに見る場所
この症状に当てはまるかどうかは、まず「どの画面で止まるか」でかなり絞れます。今回の issue では、Cowork の workspace 起動時にだけ `Failed to start Claude's workspace — Download failed. Check your internet connection and try again.` が出ています。通常の Chat は動いていて、workspace の開始だけ失敗する、という切り分けでした。macOS 側の報告ではダウンロードバーが 1〜2% で止まったあと失敗し、Windows 側の報告では UI 上はネットワーク失敗に見えるものの、ログでは VM バンドルの取得・展開・検証までは通っています。 つまり、このエラー文そのものをそのまま「回線不良」と受け取ると外す可能性があります。少なくとも報告されている 2 件では、見た目の文言と実際の原因が一致していませんでした。 macOS 側の issue は [#64234](https://github.com/anthropics/claude-code/issues
papoo.work
`respawn pane failed: fork failed: Device not configured` が出るときに見るところ
`respawn pane failed: fork failed: Device not configured` が出るときに見るところ
この症状は、Claude Code の Agent Teams と tmux の組み合わせで、teammate の spawn が失敗したときに報告されています。代表例は [#77559](https://github.com/anthropics/claude-code/issues/77559) です。報告文では、`Failed to send command to pane %2: respawn pane failed: fork failed: Device not configured` という形で失敗しており、別の pane `%3` でも同じエラーが出ています。Issue 本文では、`ENXIO / "Device not configured"` は「harness が tty を失った pane を指している」ことを示唆すると書かれています。 まず自分のケースかどうかを見分けるなら、次の2点が合っているかを確認するとよさそうです。ひとつは、Agent Teams の tmux セッションで teammate の spawn 時にだけ落ちること。もうひとつは、エラーメ
papoo.work
Error: CreateSession 400: {"error":{"message":"GitHub repository access check failed — re-authorize GitHub in settings" で止まる /ultrareview の見分け方と、手元で確認できたこと
Error: CreateSession 400: {"error":{"message":"GitHub repository access check failed — re-authorize GitHub in settings" で止まる /ultrareview の見分け方と、手元で確認できたこと
この症状は、`/ultrareview` 実行時に `CreateSession 400` で落ち、本文に `github_repo_access_denied` と `re-authorize GitHub in settings` が入っているものです。報告としては [#56000](https://github.com/anthropics/claude-code/issues/56000) と [#65708](https://github.com/anthropics/claude-code/issues/65708) が同じ文字列を含んでいました。 まず切り分けたいのは、`gh auth status` が通るかどうかではありません。issue 側では、`gh auth` が有効でも、Claude 側の GitHub 認証チェックで失敗しています。[#56000](https://github.com/anthropics/claude-code/issues/56000) の報告には、`gh auth status` はログイン済み、トークンの scope もあり、`gi
papoo.work
authentication expired と出るのに、gh は正しくログインしているように見えるとき
authentication expired と出るのに、gh は正しくログインしているように見えるとき
まず、この表示が自分のケースかを切り分けます。Issue [#67087](https://github.com/anthropics/claude-code/issues/67087) では、Claude Desktop が > GitHub CLI authentication expired. Run `gh auth login` to refresh pull request status. というバナーを繰り返し出していた一方で、同じセッション内で `gh auth status`、`gh api user`、`gh pr status` が成功していました。コメントでは、`main.log` にその日の `gh/auth` 関連の `[error]` がなく、`LocalSessions.getPrChecks` のポーリングも失敗していない、と報告されています。つまり、少なくともこの issue では「本当に期限切れの認証情報が壊れている」という単純な話ではありませんでした。 もう一つの issue [#84214](https://github.com/anthrop
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まずこの2件の issue と突き合わせる
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まずこの2件の issue と突き合わせる
このエラーに当たった場合、少なくとも今回渡された issue 報告では、症状の軸がかなりはっきりしています。 `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で、`keys` と `messages` の件数がずれている状態です。該当する報告は [#88052](https://github.com/anthropics/claude-code/issues/88052) と [#87872](https://github.com/anthropics/claude-code/issues/87872) の2件でした。どちらも open で、解決済みの報告はありません。 まず、自分のケースかどうかを見るなら、次の3点です。 エラー文に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が入っている `keys=... messages=...` のように、両者の数が1件ずれている スタックト
papoo.work
`Failed to start Claude's workspace — VM service not running.` が出たときに、まず疑うべきこと
`Failed to start Claude's workspace — VM service not running.` が出たときに、まず疑うべきこと
このエラーは、少なくとも今回読んだ issue 群では Windows 側の仮想化まわりと強く結びついています。 ただし、根っこは 1 つではなさそうです。報告を追うと、同じ文言でも原因が違うケースが混ざっています。 最初に切り分けたいのは、自分の症状がどちら寄りかです。 つまり、この系統では「Windows の仮想マシン機能が無効」「必要な機能が入っていない」側をまず疑うのが自然です。 一方で [#82688](https://github.com/anthropics/claude-code/issues/82688) では、原因がもっと単純で、`CoworkVMService` が `Stopped` になっていただけだったケースが報告されています。 この報告では、`Start-Service CoworkVMService` を通常権限で実行するとすぐ直った、とされています。アプリ側が再起動や再インストールを勧めるより先に、サービス自体を起動すべきだ、という指摘です。 この 2 件だけでも、エラー表示が同じでも対処は同じではないと分かります。 「Windows の機能が
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で引っかかるときにまず見ること
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で引っかかるときにまず見ること
この症状は、Claude Code 側で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回集められている issue は 4 件すべて open で、解決済みは 0 件でした。つまり、少なくともこの時点では「こうすれば直る」と言い切れる定番の解決策は見えていません。 最初に確認したいのは、自分のケースが報告済みのどれに近いかです。たとえば、[#93359](https://github.com/anthropics/claude-code/issues/93359) ではセッション上限に早く達したという報告があり、[#93332](https://github.com/anthropics/claude-code/issues/93332) でも短時間で使用量が 0% から 100% に跳ね上がったと書かれています。どちらも、会話量やコンテキスト消費の見え方に違和感があるという点で重なっています。 一方で、[#93492](https://github.com/
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出るときに見えていること
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出るときに見えていること
この症状は、Claude Code の画面側で `VirtualMessageList: itemKeys/messages length desync` という不整合が起きている報告として上がっています。今回の範囲では、解決策が確立したとは言えません。少なくとも、参照できた issue はどちらも open のままでした。 自分のケースかどうかを先に切り分けるなら、エラー本文に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が入っているかを見ます。報告されている差分は、`keys=25 messages=24` のように 1 件ずれている例と、`keys=192 messages=191` のように同じく 1 件ずれている例です。どちらも `range=[...,...)` を伴っていました。ここから分かるのは、メッセージ一覧の内部状態がずれたタイミングで例外が出ている、という点までです。 関連する報告は次の 2 件です。 ```text TelemetrySafeError: Vi
papoo.work
`Starting connection with timeout of 30000ms` が出るときに、まず疑うこと
`Starting connection with timeout of 30000ms` が出るときに、まず疑うこと
この文字列が出たからといって、ただちに「通信が遅い」の一言では片づきません。今回の 2 件の issue では、どちらも MCP サーバーが期待どおり起動しない、あるいは起動のしかたが想定とずれる ところまで話が進んでいました。 つまり、この症状は「接続先が遠い」よりも、「起動時にサーバーが落ちる」「同じサーバーが二重に起動する」といった、MCP 側の立ち上がり方に目を向けたほうがよさそうです。 まず見たいのは、エラーの出方です。`Starting connection with timeout of 30000ms` のあとに、`CONNECTION_CLOSED` や `Invalid Version:` が続くなら、[#93134](https://github.com/anthropics/claude-code/issues/93134) の流れにかなり近いです。少なくともその issue では、プラグインの manifest 経由で起動した `desktop-commander` の MCP サーバーが、`npm` の時点で止まっていました。 一方で、ツールがまった
papoo.work
TelemetrySafeError: task output swap refused (output is an unregistered symlink made during this session): /private/tmp/claude-501/-Users-amit-Personal-auxill-p が出るときに見えていること
TelemetrySafeError: task output swap refused (output is an unregistered symlink made during this session): /private/tmp/claude-501/-Users-amit-Personal-auxill-p が出るときに見えていること
この症状は、少なくとも 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
papoo.work
Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds) が出るとき、まず確認したいこと
Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds) が出るとき、まず確認したいこと
この症状に当てはまるかどうかは、かなりはっきりしています。Claude Cowork で `mcp__workspace__bash` を使ったときに、次のような文言が交互に出るケースです。 `Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds).` `Workspace still starting. The isolated Linux environment is booting in the background (usually 10–30 seconds). Try again shortly.` 報告された issue では、これが既存セッションでも新規セッションでも続いていました。[#76374](https://github.com/anthropics/claude-code/issues/76374) と、続報の [#92008](https://github.com/anthropics/clau
papoo.work
The model's tool call could not be parsed (retry also failed): first attempt で失敗して、同じ tool call の再送で通る症状
The model's tool call could not be parsed (retry also failed): first attempt で失敗して、同じ tool call の再送で通る症状
自分のケースかどうかを先に切り分けるなら、確認したいのは「ツール呼び出しが最初の1回だけ壊れるか」「同じ内容をもう一度送ると通るか」です。今回の issue 群では、その挙動がかなりはっきり出ています。 > "Your tool call was malformed and could not be parsed. Please retry." > "The model's tool call could not be parsed (retry also failed)." この issue では、Bash だけでなく Edit、Write、Read、ToolSearch、Workflow、MCP tools まで、ツール種別をまたいで起きると書かれています。つまり、特定のツール固有の入力ミスだけでは説明しきれない状況です。 > "The model's tool call could not be parsed (retry also failed)." 代表 issue のコメントでは、重複の可能性がある issue として [#64774](https://github.com
papoo.work
MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of を見たときに確認したいこと
MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of を見たときに確認したいこと
この症状でまず目に入るのは、Claude Code が大きなファイルを読み切れずに止まっている、という点です。issue では、`MaxFileReadTokenExceededError: File content (...) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content` という文言が繰り返し出ています。報告されているのは [#73486](https://github.com/anthropics/claude-code/issues/73486) と [#68927](https://github.com/anthropics/claude-code/issues/68927) です。 ```text MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maxim
papoo.work
`Host denied (verification failed)` が出るときに、まず疑うこと
`Host denied (verification failed)` が出るときに、まず疑うこと
このエラーは、少なくとも報告上は 2 つのまったく違う場面で出ています。ひとつは SSH でリモートフォルダに入るとき、もうひとつは Claude Desktop の Code タブで Cowork VM を作るところです。どちらも最終的には同じ文言ですが、引き金は同一とは限りません。 まず自分のケースに近いかを切り分けると、[#64425](https://github.com/anthropics/claude-code/issues/64425) は「同じホストでもホスト名の書き方で成否が変わる」例でした。`root@frigate.ahfp` や `root@pve.ahfp` では失敗し、`frigate.ahfp.local` や `orangepi@wait-room-kiosk.ahfp` では成功しています。つまり、少なくともこの報告では “接続先そのもの” より “ホスト名の表記” に症状が結びついています。 一方で [#64867](https://github.com/anthropics/claude-code/issues/64867) は Windows
papoo.work
EADDRINUSE が出るときに疑うこと: Claude Code の 2 つの報告
EADDRINUSE が出るときに疑うこと: Claude Code の 2 つの報告
まず切り分けたいのは、いま見ている `EADDRINUSE` が「自分の環境でも再現する、同じ系統の問題かどうか」です。今回の issue 群では、症状の出方が 2 通りあります。 ひとつは、Linux 上の daemon supervisor が control socket の `bind()` に失敗して落ちるケースです。[#72334](https://github.com/anthropics/claude-code/issues/72334) では、`EADDRINUSE` で `control.sock` を掴めず、`transient` 側の分岐がそのまま致命的終了する、という報告でした。コメントでは、同じ症状が `2.1.196` と `2.1.197` でも続いていたこと、`~52s` 間隔で supervisor が再起動し、競合が起きるときは `control.sock` まわりでレースが起きることが書かれています。実際のログ断片も示されています。 ```text ``` もうひとつは、Claude in Chrome の bridge が、同時に接続している
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` で止まるときに見ておくこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` で止まるときに見ておくこと
まず、自分のケースかどうかを絞ります。今回の症状クラスタでは、どちらの issue でも同じ系統のエラーが出ています。ひとつは [#88174](https://github.com/anthropics/claude-code/issues/88174)、もうひとつは [#87911](https://github.com/anthropics/claude-code/issues/87911) です。どちらも報告されている本体は `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で、`keys` と `messages` の数がずれている、と読めます。 ```json ``` ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=681 messages=680 range=[632,681)) at Bpw (B:/~BUN/root/cli:23083:33891)
papoo.work
`Error: Connection error.
`Error: Connection error.
at makeRequest (/$bunfs/root/sr` が出るときに見えているもの この症状は、Claude Code の CLI 内部で `makeRequest` から `Connection error` が投げられている状態として、少なくとも 2 件の issue で報告されています。該当するのは [#83872](https://github.com/anthropics/claude-code/issues/83872) と [#82703](https://github.com/anthropics/claude-code/issues/82703) です。どちらも報告されたエラー文字列は同じで、いま手元で確認できる範囲では、このエラー文そのものだけでは原因を一つに絞れません。 見えている issue の内容はかなり違います。#83872 は、cybersecurity 系の safeguard に触れたあとで `/rewind` を実行すると、繰り返し同じエラーに落ちるという報告でした。報告者は「cybersecurity pentest のレポート作成用の
papoo.work
`Registration: Authentication failed (401): Missing Authorization header.` が出るときに見ること
`Registration: Authentication failed (401): Missing Authorization header.` が出るときに見ること
この症状は、`claude remote-control` の登録段階で止まり、401 とともに `Missing Authorization header` と出るケースです。今回の報告では、[`#83958`](https://github.com/anthropics/claude-code/issues/83958) と [`#83976`](https://github.com/anthropics/claude-code/issues/83976) のどちらも、登録フェーズで同じエラーに落ちています。 まず切り分けたいのは、「単に認証が切れている」のか、「Authorization ヘッダー自体が送られていない」のかです。issue #83958 では、当日の新しく発行された OAuth トークンでは Authorization ヘッダーが送られず、同じ CLI バージョンでも朝は古いトークンで送れていた、という観察が書かれています。つまり、少なくともその報告では、ユーザー操作のミスというより CLI 側の挙動に見えます。 issue #83976 では、同じアカウ
papoo.work
`MCP server process is running, the new files are not copied` が出るときにまず見ること
`MCP server process is running, the new files are not copied` が出るときにまず見ること
この症状は、Claude Code のプラグインを更新したのに、MCP server が古いファイルを掴んだままで新しい内容が反映されない、という報告です。参照できる報告は [#72678](https://github.com/anthropics/claude-code/issues/72678) と [#75674](https://github.com/anthropics/claude-code/issues/75674) の 2 件で、どちらも closed になっていますが、コメントを見る限り「再現手順が足りないので調査継続のために新しい issue を出してほしい」という扱いでした。 まず、自分のケースかどうかを切り分けるなら、次の見え方に一致するかを見ます。issue 本文では、プラグイン更新時に MCP server process が動いていると、新しいファイルが `~/.claude/plugins/data/<plugin>/` にコピーされず、`installed_plugins.json` だけは新しい version を指す一方で、実体の binary
papoo.work
Claude Code で `HTTP 502` が出るときに見ておくこと
Claude Code で `HTTP 502` が出るときに見ておくこと
まず、この `HTTP 502` が自分のケースかどうかは、出方でだいたい分かれます。今回集まっている報告では、`claude code` の実行時に `API Error: 502 Bad Gateway` と返るケースと、remote/cloud sandbox で GitHub へのアクセス自体が `502 Bad Gateway` に落ちるケースの 2 つがありました。前者は [#69785](https://github.com/anthropics/claude-code/issues/69785)、後者は [#73273](https://github.com/anthropics/claude-code/issues/73273) です。 もう一方の [#73273](https://github.com/anthropics/claude-code/issues/73273) は、`isolation: "remote"` の background agent で GitHub につながらない話です。ここでは、許可済みの private repo の `git clo
papoo.work
Error: ELOOP: too many symbolic links encountered, open '/pr で止まるときに見えたこと
Error: ELOOP: too many symbolic links encountered, open '/pr で止まるときに見えたこと
この症状は、`Error: ELOOP: too many symbolic links encountered, open '/private/tmp/claude-...` で始まるエラーとして issue に上がっています。今回確認できたのは、どちらの報告も `/private/tmp/claude-...` 配下の一時パスを開く場面で `ELOOP` が出ていることです。少なくとも報告ベースでは、Claude Code の操作中に一時領域のファイルを開こうとして失敗しているように見えます。 参照できた issue は次の 2 件です。どちらも open で、解決済みではありません。 報告内容をそのまま見ると、`ELOOP` が出る直前のパスはどちらも似ています。1 件目は `competition-module` を含むパス、2 件目は `btf3k0ktq.output` を含むパスでした。完全な再現手順までは issue からは読めませんが、少なくとも「一時ディレクトリ下の対象ファイルを開くときにシンボリックリンクが絡んでいる」状態を疑うのが自然です。とはいえ、ここまでしか
papoo.work
UnexpectedApiResponseError: API returned an empty or malformed response を見たときにまず疑うこと
UnexpectedApiResponseError: API returned an empty or malformed response を見たときにまず疑うこと
この症状は、Claude Code 側が「HTTP 200 は返ってきたのに、中身が期待した応答になっていない」と判断したときに出ています。今回渡された issue はどちらも同じ系統で、非ストリーミングのリクエストに対して event-stream が返ってきた、という報告でした。 自分のケースかどうかを見分ける手がかりは、エラーメッセージの中に `content-type event-stream` や `body is an event stream` が含まれているかどうかです。[#87842](https://github.com/anthropics/claude-code/issues/87842) では「non-streaming request was answered with a stream」と明記されていましたし、[#89232](https://github.com/anthropics/claude-code/issues/89232) でも同じ文言が出ています。どちらも HTTP 200 で返ってきているのに、レスポンスの形式が合っていません。 issu
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync で止まるときに見えていたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync で止まるときに見えていたこと
まず、自分の症状が同じかどうかは、エラーメッセージの形でかなり絞れます。今回のクラスタでは、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ていて、`keys=... messages=... range=[...,...)` のように itemKeys と messages の件数差まで表示されています。本文で確認できたのはこの型のエラーで、少なくとも issue 報告上は別件を含めて同じクラスタとして扱われていました。 報告されていた issue は 2 件です。[#83109](https://github.com/anthropics/claude-code/issues/83109) では `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=325 messages=324 range=[279,325))`、[#81878](https://github.com/an
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の切り分けメモ
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の切り分けメモ
まず、自分のケースかどうかを先に見ます。今回の症状は、Claude Code の issue に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=82 messages=81 range=[51,82))` という形で報告されています。関連する報告は [#84239](https://github.com/anthropics/claude-code/issues/84239) と [#84283](https://github.com/anthropics/claude-code/issues/84283) の 2 件で、少なくとも issue 上ではどちらも同じ種類のエラー文字列を含んでいました。 この時点で言えるのは、エラー名がかなり具体的で、`itemKeys` と `messages` の件数がずれている、という内部状態の不整合を示しているらしいことです。ただし、issue の本文だけでは、何がそのずれを起こしたのかまでは分かりません。少なくとも、報告者は「指示どおり
papoo.work
gh が出てくるのに GitHub 連携が効いているとは限らない話
gh が出てくるのに GitHub 連携が効いているとは限らない話
「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
papoo.work
`Error: Lock is already released
`Error: Lock is already released
at <anonymous> (/$bunfs/` が出るときに見えているもの この症状は、少なくとも報告上は Claude Code の CLI 内部で `Error: Lock is already released` が出ているケースです。Issue では、入力プロンプトの途中で短い入力が別の操作として拾われる、あるいはセッション中の処理でトークンを使い切る、といった別の現象と一緒に報告されています。該当する報告は [#65137](https://github.com/anthropics/claude-code/issues/65137) と [#76742](https://github.com/anthropics/claude-code/issues/76742) です。 ただ、ここで大事なのは「同じ文字列が出たから同じ原因」とは言い切れないことです。少なくとも今回の issue 群だけを見ると、入力まわりの誤作動と、セッション内の消費が想定外に大きくなった件が混ざっています。どちらも最終的に同じ `Lock is already released` に見えているだけか
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_ no low surrogate in string が出るときに見えること
Error: 400 {"type":"error","error":{"type":"invalid_request_ no low surrogate in string が出るときに見えること
この症状は、Claude Code から送ったリクエスト本文が JSON として受け付けられず、`no low surrogate in string` というエラーで 400 が返っているケースとして報告されています。今回渡された issue では、少なくとも [#60394](https://github.com/anthropics/claude-code/issues/60394) と [#68744](https://github.com/anthropics/claude-code/issues/68744) の両方で、同じ形のエラーが出ています。 まず自分のケースかどうかを見分けるには、エラーメッセージの中に次の文言があるかを確認します。 ```text Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The request body is not valid JSON: no low surrogate in string: line 1 column 19562
papoo.work
Error: 1: Command failed with ERR_STREAM_PREMATURE_CLOSE: code --force --install-extension anthropic.claude-code が出たときに見えたこと
Error: 1: Command failed with ERR_STREAM_PREMATURE_CLOSE: code --force --install-extension anthropic.claude-code が出たときに見えたこと
この文字列が出ているなら、少なくとも報告上は `code --force --install-extension anthropic.claude-code` の実行が `ERR_STREAM_PREMATURE_CLOSE` で途中終了しています。今回の手元の出力と、同じ症状として挙がっていた issue を照らすと、これは Claude Code のインストール処理まわりで起きた失敗として読むのが自然です。 まず切り分けたいのは、自分のケースが「同じエラー文字列に当たっているだけ」なのか、「同じインストール失敗の流れ」なのかです。今回参照できた issue は 2 件で、どちらも報告されたエラーは同じでした。 どちらの issue でも、見えているエラーは次の形です。 ```text Error: 1: Command failed with ERR_STREAM_PREMATURE_CLOSE: code --force --install-extension anthropic.claude-code Premature close at cl1 (/$bunfs/root/s
papoo.work
`temporarily unavailable` が出て Bash や Edit が止まるときに見ること
`temporarily unavailable` が出て Bash や Edit が止まるときに見ること
まず、自分のケースかどうかはかなり見分けやすいです。Claude Code の auto mode で Bash か Edit を実行しようとしたとき、次のような文言が出て処理が止まるなら、今回の症状に当たっている可能性があります。 > `claude-opus-4-7 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now. Wait briefly and then try this action again. If it keeps failing, continue with other tasks that don't require this action and come back to it later.` この報告は issue [#62170](https://github.com/anthropics/claude-code/issues/62170) にあり、Bash safety classifier が `claude-opus-4-7` で
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` に出る長さ不一致、今のところ未解決
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` に出る長さ不一致、今のところ未解決
まず、この症状が自分のケースかどうかを切り分けます。Issue 上で報告されているのは、どちらも同じ系統のエラーです。 > `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=812 messages=811 range=[777,812))` つまり、少なくとも issue から確認できる範囲では、このエラーは「何かのメッセージ一覧が、キー数と本文数で 1 件ずれている」状態で出ています。 ただし、なぜその不一致が起きるのか、Claude Code 側の表示の問題なのか、特定の入力内容で誘発されるのか は、今回の報告だけでは分かりません。解決済み issue も確認できませんでした。 手元で確認できた環境情報は次のとおりです。これは症状の再現ログではなく、検証時点の実機情報です。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したこと
この症状は、`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
papoo.work
Error: EINVAL: invalid argument, open '/private/tmp/claude-5…' が出るときに見えたこと
Error: EINVAL: invalid argument, open '/private/tmp/claude-5…' が出るときに見えたこと
この症状は、Claude Code のサブエージェントが動いている最中に、`/private/tmp/claude-501/.../tasks/...output` のようなパスを `open` しようとして `EINVAL: invalid argument` で落ちる、という形で報告されています。手元で確認できたのは issue 報告の文面だけで、再現手順や恒久的な回避策までは確認できていません。 自分のケースかどうかを見分けるなら、まずエラーメッセージの中に次の形があるかを見ます。`/private/tmp/claude-5` で始まる一時領域のパス、`tasks/` ディレクトリ、そして `.output` か `.outp...` のようなファイル名が並んでいれば、報告された症状とかなり近いです。 issue [#81993](https://github.com/anthropics/claude-code/issues/81993) では、macOS 上の Claude Code CLI、Apple Silicon、1つの長時間セッションで複数のバックグラウンド suba
papoo.work
2 件の Claude Code 障害を切り分ける
2 件の Claude Code 障害を切り分ける
このクラスタには、性質の違う 2 つの issue が入っています。どちらも解決済みですが、症状の出方は別物です。自分のケースかどうかは、まず「Bash tool なのか Monitor tool なのか」と「macOS なのか」を見るのが早いです。 1つ目は [#64426](https://github.com/anthropics/claude-code/issues/64426) で、Bash tool のコマンドから `-flag` らしきトークンが消えるという報告です。条件はかなり具体的で、コマンド置換 `$(...)` やバッククォートの中に、さらに `$` を使った展開が入っていると、実行前に ` -<flag>` が抜かれると書かれています。issue 本文では「モデルは正しいコマンドを送っているが、実際にシェルで走るのは壊れたコマンドだ」と説明されています。環境は Claude Code 2.1.159、macOS の Darwin 24.6.0、Apple Silicon、`/bin/zsh 5.9` です。 2つ目は [#63050](https://githu
papoo.work
`The operation timed out.` が何度も出て処理が止まるときに見えるもの
`The operation timed out.` が何度も出て処理が止まるときに見えるもの
この症状は、少なくとも issue [#64500](https://github.com/anthropics/claude-code/issues/64500) と [#69311](https://github.com/anthropics/claude-code/issues/69311) で報告されています。どちらも報告されたエラーは同じく `The operation timed out.` でした。 自分のケースかどうかを先に見るなら、単発の失敗ではなく、同じ操作が何度も止まり続けるかが目印です。[#64500](https://github.com/anthropics/claude-code/issues/64500) では、モデルの tool call の解析に失敗したあとに再試行も失敗し、そのまま長時間ハングしています。ログには次のような反復が残っています。 ```text ⏺ The model's tool call could not be parsed (retry also failed). ✻ Churned for 21m 49s ❯ 繼續 ⏺ Th
papoo.work
String to replace not found が出るときに見るところ
String to replace not found が出るときに見るところ
この症状は、見た目には「編集したい文字列がそのままあるのに、`Edit` が失敗する」ように見えます。issue に出ている報告は、完全に同じ原因ではなさそうです。ただ、少なくとも「`String to replace not found` が出て編集が進まない」という点では重なっています。 最初に確認したいのは、あなたが遭遇しているのが「ファイルの内容は合っているのに置換できない」のか、「そもそも Claude が成功したように言っているだけで、実際には反映されていない」のかです。前者は `Edit` の `old_string` 不一致、後者は作業完了の見かけと実体のずれです。#64212 では、`old_string` がブランチ上のファイルと一致していない `Edit` 呼び出しがあり、`String to repla...` という失敗が記録されています。#52482 では、全角 CJK 記号を含む箇所で、モデルが半角記号にずれて `old_string` を作ってしまい、その結果として `String to replace not found` が起きると説明されています。
papoo.work
exit code 126 が出るときにまず見るところ
exit code 126 が出るときにまず見るところ
`exit code 126` だけでは原因は絞れませんが、今回の 2 件の issue はどちらも「Claude Code の Bash tool が、sandbox 有効時に毎回失敗する」という共通点がありました。しかも失敗は単発ではなく、`pwd` のような簡単なコマンドでも起きています。 症状の出方が似ていても、環境はかなり違います。ひとつは WSL2 上の Linux で、`sandbox.enabled: true` と `filesystem.denyRead` や `permissions.deny Read(...)` の組み合わせで起きています。もうひとつは macOS で、ログインシェルが zsh のときに起きています。前者は [#51126](https://github.com/anthropics/claude-code/issues/51126)、後者は [#77466](https://github.com/anthropics/claude-code/issues/77466) です。 WSL2 側の issue では、表示上は `Exit code
papoo.work
`Remote Control is not yet enabled for your account.` が出るときに見えていること
`Remote Control is not yet enabled for your account.` が出るときに見えていること
この症状は、`claude remote-control` を実行した瞬間に ```text Error: Remote Control is not yet enabled for your account. ``` で止まる、という形で報告されています。関連する issue は [#61890](https://github.com/anthropics/claude-code/issues/61890)、 [#81459](https://github.com/anthropics/claude-code/issues/81459)、 [#63198](https://github.com/anthropics/claude-code/issues/63198) です。 まず、このエラー文がそのまま出ているなら、少なくとも issue 報告上は「Remote Control の有効化判定で弾かれている」状態です。`#61890` では、`--verbose` を付けてもエラー行以外の追加出力がなく、ハンドシェイクや通信の前にクライアント側で拒否されているように見える、と書かれてい
papoo.work
`[Tool result missing due to internal error]` が出るときに最初に見るところ
`[Tool result missing due to internal error]` が出るときに最初に見るところ
このエラーは、Claude Code の `Bash` ツールまわりで出ています。今回の issue では、見え方は違ってもどちらも「ツールの結果が内部エラー扱いで欠ける」という同じ症状でした。`Bash` に対する `PreToolUse` hook が `defer` を返したときにコマンドが実行されず `"[Tool result missing due to internal error]"` になる例が [#64389](https://github.com/anthropics/claude-code/issues/64389) にあり、別件では並列の `Bash` 呼び出し 7 件のうち 4 件が同じ内部エラーになった例が [#62161](https://github.com/anthropics/claude-code/issues/62161) にあります。 まず切り分けたいのは、あなたの環境に `settings.json` や `settings.local.json` があるかどうかです。今回、筆者の環境ではどちらも見つかりませんでした。 ```text ~/
papoo.work
TelemetrySafeError: task output swap refused (output file identity changed): これが出たら確認したいこと
TelemetrySafeError: task output swap refused (output file identity changed): これが出たら確認したいこと
この症状は、issue [#92151](https://github.com/anthropics/claude-code/issues/92151) と [#92150](https://github.com/anthropics/claude-code/issues/92150) の両方で報告されています。どちらも件名は同じで、本文には「the agent has been lying and doing nothing」とあり、実際にはタスクを実行していないのに完了したように見える、という訴えです。報告されたエラーは次のものです。 ```text TelemetrySafeError: task output swap refused (output file identity changed): /private/tmp/claude-501/-Users-michaeltabet/773c3a12-2bac-4331-a8d2-8e80e1e08eb6/tasks/b3cxl28wu.output at N (/$bunfs/r / TelemetrySafeError:
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
この症状は、少なくとも今回渡された 2 件の issue では同じエラーメッセージとして現れています。 > `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=26 messages=25 range=[0,26))` もう 1 件でも同系統の報告がありました。 > `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=252 messages=251 range=[236,252))` どちらも、報告本文だけを見る限りでは「メッセージ一覧の件数」と「キー一覧の件数」が 1 件ずれている状態です。ですが、ここから先の原因は issue の報告内容だけでは切り分けきれません。少なくとも、[#80361](https://github.com/anthropics/claude-code/issues/80361) では OAuth テスト用の画面を準備している最中に安全ガードが誤っ
papoo.work
Claude Fable 5 is currently unavailable が出るときに、まず見るべきこと
Claude Fable 5 is currently unavailable が出るときに、まず見るべきこと
この文字列が出ているだけでは、同じ症状とは限りません。今回集められている issue では、少なくとも 2 つの見え方がありました。 ひとつは、Claude for Excel add-in で入力欄に打った文字が Claude 側ではなく Excel のアクティブセルに入ってしまうケースです。報告では、セル選択のチップが閉じても戻ってきて、同時にパネル内に “Claude Fable 5 is currently unavailable” が出ていました。モデル表示は Opus 4.8 だったと書かれています。これは [#72577](https://github.com/anthropics/claude-code/issues/72577) です。 もうひとつは、`/model` ピッカーで Fable 5 がグレーアウトして “Claude Fable 5 is currently unavailable” と出る一方、起動時のバナーでは “Fable 5 is back.” と表示されるケースです。こちらは [#73640](https://githu
papoo.work
Error: Error during compaction: API Error: Usage credits req で止まるときに見えていたこと
Error: Error during compaction: API Error: Usage credits req で止まるときに見えていたこと
この症状は、`/compact` の途中で `Error: Error during compaction: API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to standard context` という形で失敗し、セッションの圧縮が進まなくなるものです。報告されている issue は [#64031](https://github.com/anthropics/claude-code/issues/64031) と [#63718](https://github.com/anthropics/claude-code/issues/63718) の 2 件で、どちらも closed です。 今回の材料だけで言える範囲では、少なくとも次の 2 つが同じクラスタに入っています。ひとつは「コンパクション中に API エラーが出る」ケース、もうひとつは「Sonnet-4.6 を使っていて 200k の context limit
papoo.work
`This folder contains Claude's app data and can't be shared w` が出たときにまず見ること
`This folder contains Claude's app data and can't be shared w` が出たときにまず見ること
このエラーが出るケースは、少なくとも issue 報告上では二つに分かれています。ひとつは、もともと動いていた作業フォルダがアップデート後に急に弾かれるケース。もうひとつは、フォルダ内に `Skills`、`Scheduled`、`Artifacts`、`.claude/` などが絡んでいて、同じ文言で止まるケースです。該当する報告は [#78368](https://github.com/anthropics/claude-code/issues/78368) と [#89916](https://github.com/anthropics/claude-code/issues/89916) です。 見分けるときは、まず「そのフォルダは以前は問題なく使えていたか」と「中に `.claude/` があるか、あるいは `Skills` などの名前のサブフォルダがあるか」を確認するのが早いです。少なくとも issue の記述では、見た目上は Claude のアプリデータが入っていないのに、この文言で拒否される例がありました。[#78368](https://github.com/anthr
papoo.work
`thinking blocks ... cannot be modified` が出てセッションが戻らないとき
`thinking blocks ... cannot be modified` が出てセッションが戻らないとき
この症状に心当たりがあるなら、まず見分けたいのは「一度だけ 400 が出た」のか、「その後ずっと同じ 400 で詰まる」のかです。今回の issue では、後者が報告されています。途中で止まった会話が、その後の送信でも毎回 `thinking` 系のブロック不正として落ち続ける、という流れです。 報告されている代表例は [#63374](https://github.com/anthropics/claude-code/issues/63374) と [#63410](https://github.com/anthropics/claude-code/issues/63410) です。どちらも最終的には同じエラー文に行き着きます。 > `API Error: 400 messages.N.content.M: \`thinking\` or \`redacted_thinking\` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in th
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに見えているもの
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに見えているもの
まず、この症状に当てはまるかどうかは、報告されている例を見るとかなりはっきりしています。`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文字列が出ていて、スタックトレースに `nHt (B:/~BUN/root/chunk-9891yaqw.js:36:25132)` が含まれているケースです。今回の材料では、同じ症状として [#91880](https://github.com/anthropics/claude-code/issues/91880) と [#91653](https://github.com/anthropics/claude-code/issues/91653) の 2 件があり、どちらも open のままです。解決済みの報告はありませんでした。 もう一件の [#91653](https://github.com/anthropics/claude-code/issues/91653) は少し違っていて、Windows 11 で agents view を開い
papoo.work
ERR_NAME_NOT_RESOLVED が出るときに最初に見ること
ERR_NAME_NOT_RESOLVED が出るときに最初に見ること
`ERR_NAME_NOT_RESOLVED` は、今回の issue 報告では Claude Desktop 起動直後の通信が DNS 解決で落ちている形で出ています。読者の環境でも、起動時にネットワーク系の初期化が失敗しているなら、この症状に近い可能性があります。 ```text Health check fetch failed: Error: net::ERR_NAME_NOT_RESOLVED ``` この報告で分かるのは、少なくともアプリ内部の Chromium ネットワークスタックが、起動時の API 呼び出しを名前解決エラーで通せていない、という点です。少なくとも issue の記述上は、アプリ本体の表示崩れではなく、起動直後の通信失敗が中心に見えます。 切り分けの起点は単純です。もし同じ `ERR_NAME_NOT_RESOLVED` が出ているなら、「アプリだけが落ちる」のか、「名前解決そのものが不安定なのか」を分けて見たほうがよさそうです。#73042 の報告は Windows 10 Enterprise、App Version 1.17377.2、Electro
papoo.work
exit code 255 で SSH が落ちるときに見るもの
exit code 255 で SSH が落ちるときに見るもの
まず自分のケースかどうかを切り分けます。今回の issue 群では、どちらも Claude Code から SSH を投げたときに `exit code 255` で失敗しています。ただし、同じ 255 でも中身は違います。 ```text Error: Exit code 255 Connection timed out during banner exchange Connection to UNKNOWN port 65535 timed out ``` 一方、[#77678](https://github.com/anthropics/claude-code/issues/77678) では、背景が違います。issue の要約では、Claude Code の Bash tool で SSH を呼ぶと `No user exists for uid 501` が出て、standalone の `claude` CLI では同じコマンドが動くと報告されています。つまり、同じ SSH 失敗でも、こちらはネットワーク到達性というより実行環境側の問題に見えます。 `#68497` のほう
papoo.work
`Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"}` が出て止まるときに見えていたもの
`Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"}` が出て止まるときに見えていたもの
この症状は、Claude Code が編集や生成を進めようとした直後に、Anthropic API 側のエラーとして ```text Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"},"request_id":"req_011CbWYp22Y864uHoBmCJ8hy"} ``` のような応答を返し、作業が進まなくなるものです。報告されている issue はどちらも同じエラーメッセージで、[#63572](https://github.com/anthropics/claude-code/issues/63572) と [#61565](https://github.com/anthropics/claude-code/issues/61565) です。 切り分けの入口は単純で、あなたのケースが「ファイルの中身や依頼内容に関係なく、このエラー文字列で止まる」かどうかです。
papoo.work
`Invalid OAuth Request — Missing redirect_uri parameter` が出て Claude Code の OAuth ログインが進まないとき
`Invalid OAuth Request — Missing redirect_uri parameter` が出て Claude Code の OAuth ログインが進まないとき
まず、この症状に当てはまりやすいのは、ブラウザが開いた先で `Invalid OAuth Request — Missing redirect_uri parameter` と表示され、ログイン処理が最後まで進まないケースです。Issue では、`claude auth login` のあとにブラウザが `claude.ai/cai/oauth/authorize` 側へ飛び、認証完了後に `https://claude.com/cai/oauth/authorize` 付近で同じ文言が出る流れが報告されています。`claude setup-token` や Console Anthropic の “Continue with Claude Pro” でも再現した例がありました。([#91911](https://github.com/anthropics/claude-code/issues/91911)) 同じ症状は、別の報告でも見え方がかなり近いです。`/login` の直後にブラウザで OAuth エラーになり、しかも別マシンの別ユーザーでも同じエラーが出た、という内容でした。
papoo.work
`Tell the user that these servers need to be authorized … and` が出るのに、実際は使えることがある
`Tell the user that these servers need to be authorized … and` が出るのに、実際は使えることがある
まず切り分けたいのは、MCP 接続が本当に未認証なのか、それとも「未認証だと言われているだけ」なのかです。今回の症状は後者として報告されています。`claude.ai` の OAuth connector がすでに認証済みで、同じセッション内でツール呼び出しも成功しているのに、セッション開始時の system reminder に「requires authentication before their tools can be used」と出て、さらに > “Tell the user that these servers need to be authorized … and that the capability is unavailable until they do.” という指示まで載る、という内容です。該当する issue は [#76320](https://github.com/anthropics/claude-code/issues/76320) と [#77534](https://github.com/anthropics/claude-code/issues
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたときに確認したいこと
このエラーは、GitHub Issue 上では複数件まとまって報告されています。手元で見えた範囲では、いずれも同じ文言の `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ており、たとえば [#79235](https://github.com/anthropics/claude-code/issues/79235)、[#79179](https://github.com/anthropics/claude-code/issues/79179)、[#79166](https://github.com/anthropics/claude-code/issues/79166)、[#79272](https://github.com/anthropics/claude-code/issues/79272) に含まれていました。 ただし、報告内容だけでは原因はひとつに絞れません。モデルの切り替えに見えるという報告もあれば、ネットワーク試験の最中に止まったという報告もあり、Issue の本文から
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — `keys=249 messages=248` が出たときに見ること
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — `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、防御的なセキュリティ作業、通常のデプロイ作業
papoo.work
exit code 139 で `claude` が起動直後に落ちるときの見分け方
exit code 139 で `claude` が起動直後に落ちるときの見分け方
`claude` を打った瞬間に何も表示されず終わる。`claude --help` も `claude --version` も同じで、終了コードが 139 になる。今回の issue 群は、この形にかなり近い症状です。 報告されているのは、Ubuntu 26.04 LTS の VirtualBox VM 上で `claude` が即死した例と、Linux x86_64 上で 2.1.243 が起動直後に SIGSEGV で落ちる例です。どちらも、通常の対話画面が出る前に失敗しています。[#63635](https://github.com/anthropics/claude-code/issues/63635) と [#89390](https://github.com/anthropics/claude-code/issues/89390) では、少なくともその挙動が一致しています。 今回の一次情報では、私の環境で再現確認はできていません。実際に取れたのは次の環境情報だけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x8
papoo.work
`WorktreeRemove hook failed` が出るのに、hook 自体は悪くないことがある
`WorktreeRemove hook failed` が出るのに、hook 自体は悪くないことがある
最初に切り分けたいのは、「本当に 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 状態を検証できず削除を拒んでいる、という説明になっています。つまり、見えているエラー文と実際の原因がずれている可能性があ
papoo.work
Permission to use mcp__workspace__bash has been denied. が出続けるときに確認したこと
Permission to use mcp__workspace__bash has been denied. が出続けるときに確認したこと
この症状は、Cowork で `mcp__workspace__bash` と `mcp__workspace__web_fetch` が毎回拒否される、という形で報告されています。関連する issue は [#91582](https://github.com/anthropics/claude-code/issues/91582) と [#91561](https://github.com/anthropics/claude-code/issues/91561) です。 まず、自分のケースかどうかは次の見え方で切り分けられます。Issue 報告では、`mcp__workspace__bash` だけでなく `mcp__workspace__web_fetch` も同時に拒否され、しかも毎回すぐに ```text Permission to use mcp__workspace__bash has been denied. ``` が返るとされています。許可確認のプロンプトは一度も出ず、Read / Glob / Grep / WebSearch / remote MCP conne
papoo.work
claude が `command not found` になるのに、インストール自体は成功したように見える
claude が `command not found` になるのに、インストール自体は成功したように見える
新しいターミナルを開くたびに `claude` が見つからない。けれど、インストールの途中では成功メッセージが出ている。そんなときは、まずこの2つの issue が自分の症状に近いかを見たほうがいいです。 1つは、`install.sh` か `claude install` が「launcher と shell integration を設定した」と表示するのに、`~/.local/bin` を `PATH` に追加していないケースです。報告は macOS / zsh ですが、症状そのものは「入ったはずなのにシェルから見えない」です。該当 issue は [#76060](https://github.com/anthropics/claude-code/issues/76060) です。 もう1つは、自動更新の途中で optional dependency のダウンロードが詰まり、更新は成功扱いで終わるのに、次の起動で `claude: command not found` になるケースです。こちらは [#72690](https://github.com/anthropics/c
papoo.work
exit code 127 が出るときにまず見るところ
exit code 127 が出るときにまず見るところ
手元の issue を見る限り、`exit code 127` は少なくとも 2 つの別系統で報告されています。ひとつは macOS の Claude Desktop / Cowork まわりで、Claude Code のプロセス自体が起動できずに落ちるケースです。もうひとつは、プロジェクト内に置いたカスタム subagent が Agent tool に現れないという報告です。後者は症状の説明に `exit code 127` そのものは出ていませんが、同じ症状クラスタとして渡されているため、周辺で起動や読み込みに失敗している可能性はあります。ただし、そこは現時点では断定できません。 まず、自分のケースがどちら寄りかを切り分けます。 `exit code 127` が前面に出るのは、[#58495](https://github.com/anthropics/claude-code/issues/58495) の報告です。ここでは macOS Intel、App Store 版の Claude Desktop、native install の Claude Code CLI という構
papoo.work
Claude Code が exit code 134 で落ちるときに、まず見るべき差分
Claude Code が exit code 134 で落ちるときに、まず見るべき差分
自分のケースかどうかを先に切り分けるなら、まず「Claude Desktop に付属している Claude Code だけが落ちるのか」を確認したほうが早いです。issue には、同じ macOS 12 系の機械で、Desktop app の bundled build だけが起動直後に死に、standalone CLI は動いた例がありました。つまり、少なくとも報告上は「macOS が古いから全部だめ」という話ではありません。 issue に出ているエラーは、どれも「起動直後に dyld がシンボルを見つけられず abort する」という形です。たとえば #91381 は `_DNSServiceGetAddrInfoEx`、#75206 は libc++ の symbol not found、#91550 も `_DNSServiceGetAddrInfoEx` でした。見た目は違っても、どれも `exit code 134` に落ち着いています。 #75206](https://github.com/anthropics/claude-code/issues/75206) では、
papoo.work
thinking blocks cannot be modified が出るときに起きていたこと
thinking blocks cannot be modified が出るときに起きていたこと
まず、このエラーが出るケースかどうかを切り分けます。手元の issue 報告では、どれも `thinking` か `redacted_thinking` のブロックが、最新の assistant message に入ったあとに壊れています。しかも一度壊れると、そのセッションの続行や再開がずっと失敗し続けます。 たとえば [#63258](https://github.com/anthropics/claude-code/issues/63258) では、バックグラウンド実行した subagent が最初のターンで即座に落ちています。`Explore` agent でも一般の `Agent` でも同じで、ツール呼び出しに進む前にこの 400 が返っていました。再試行しても同じでした。 共通しているのは、単発の一時的な失敗ではなく、会話履歴のどこかにある assistant message の `thinking` 系ブロックが、送信し直す過程で「元の応答のまま」でなくなってしまっている点です。issue の本文では、`thinking` の中身が空になっているのに signature
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.22: `thinking` or `redacted_thinking` blocks in the latest assi を踏んだときに確認したいこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.22: `thinking` or `redacted_thinking` blocks in the latest assi を踏んだときに確認したいこと
この症状は、Claude Code の会話が途中から進まなくなり、API から 400 を返され続けるタイプのものです。報告されている文言はほぼ共通していて、`thinking` か `redacted_thinking` ブロックを最新の assistant message から変更できない、という内容になっています。 Issue 群を見る限り、[#63121](https://github.com/anthropics/claude-code/issues/63121)、[#63341](https://github.com/anthropics/claude-code/issues/63341)、[#63247](https://github.com/anthropics/claude-code/issues/63247)、[#63337](https://github.com/anthropics/claude-code/issues/63337)、[#63404](https://github.com/anthropics/claude-code/issues/63404)、
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で始まる desync は、いま報告されている同型の症状です
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で始まる desync は、いま報告されている同型の症状です
この症状は、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` を含むエラーとして、少なくとも 2 件の issue に出ています。報告された環境はいずれも Windows で、Claude Code の Version は `2.1.257` でした。現時点で解決済みの issue は 0 件です。 まず、自分のケースかどうかを見分けるなら、エラー文字列がほぼそのまま一致するかを確認するのがいちばん早いです。報告内容では、`keys=115 messages=114 range=[58,115)` と `keys=370 messages=369 range=[328,370)` のように、`keys` と `messages` の件数が 1 ずれていました。つまり、見えているのは「メッセージ一覧の内部整合性が崩れた」タイプの障害で、少なくとも issue 上は入力文そのものより、表示・追跡しているメッセージ列の不整合に寄っています。 関連する報告は [#91323](https://gi
papoo.work
`Remote Control disconnected — Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message.` が出るときに見るところ
`Remote Control disconnected — Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message.` が出るときに見るところ
この症状は、少なくとも issue [#79057](https://github.com/anthropics/claude-code/issues/79057) と [#76954](https://github.com/anthropics/claude-code/issues/76954) で報告されています。 どちらも共通しているのは、Desktop 側でセッションを開き直したときに Remote Control 接続が失敗し、同じ文言のエラーが出ることです。 まず、自分のケースがこの系統かを切り分けると話が早いです。 同じ issue のコメントでは、これは cloud-sandbox の routine 実行ではなく、ローカルホストの scheduled-task session だと補足されています。つまり、セッション一覧にはアカウント単位で出てくるが、実体は最初に動いた端末側にあった、ということです。 > `Remote Control disconnected — Your terminal's Claude Code session stopped res
papoo.work
`Subprocess initialization did not complete within 60000ms — ` が出るときに見るべきこと
`Subprocess initialization did not complete within 60000ms — ` が出るときに見るべきこと
この症状は、少なくとも issue 報告上では、Claude Code の subprocess 起動後に初期化が 60 秒で打ち切られたときに出ています。該当する報告は [#72315](https://github.com/anthropics/claude-code/issues/72315) と [#91149](https://github.com/anthropics/claude-code/issues/91149) です。どちらもエラーメッセージは同じで、ホスト側は「authentication and network connectivity」を疑う文言を出しています。 まず切り分けたいのは、「認証やネットワークそのものが壊れている」のか、「subprocess は立ち上がるが、その後のホスト側 handoff で止まっている」のかです。後者は [#91149](https://github.com/anthropics/claude-code/issues/91149) の報告内容にかなり近く、そこでは IDE extension host から起動した Claud
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} で止まる Claude Code の 429
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} で止まる Claude Code の 429
この症状は、GitHub Issue 上では少なくとも [#71635](https://github.com/anthropics/claude-code/issues/71635) と [#71504](https://github.com/anthropics/claude-code/issues/71504) で報告されています。どちらも、`API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited` という説明と、同じ 429 系のエラー文字列が付いていました。報告内容だけを見る限り、利用者側の使用量上限ではなく、サーバー側の一時的な制限として扱われています。 実際の報告では、次のように出ています。 ```text 報告されたエラー: Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"},"request_id":"req_011CcQs8
papoo.work
`Unable to connect to API (ConnectionRefused)` が出るときにまず見ること
`Unable to connect to API (ConnectionRefused)` が出るときにまず見ること
この症状は、Claude Code が API への接続に失敗したときに出ています。今回の材料の中では、同じ文言が出ている issue は 2 件あり、Windows の報告 [#71485](https://github.com/anthropics/claude-code/issues/71485) と、macOS の報告 [#75897](https://github.com/anthropics/claude-code/issues/75897) です。どちらも「接続できない」こと自体は共通していますが、切り分けの材料は少し違います。 最初に見るべきなのは、Claude Code 以外では API に届いているかどうかです。[#71485](https://github.com/anthropics/claude-code/issues/71485) では、`claude auth status` はログイン済みで、`api.anthropic.com:443` への TCP テストも成功しています。さらに HTTPS は HTTP 401 まで返っており、少なくともネットワー
papoo.work
Claude Code で `HTTP 500` が返るときに見えていること
Claude Code で `HTTP 500` が返るときに見えていること
まず切り分けると、この症状は少なくとも 2 件の報告で同じ文言が出ています。ひとつは VS Code 拡張で Claude Code を使っているときに、もうひとつはターミナルからのリクエストで、どちらも `500 Internal server error` です。報告内容だけを見る限り、特定のファイル操作に限られた失敗ではなく、Claude Code への要求そのものが通らない状態に見えます。 該当する issue は [#70336](https://github.com/anthropics/claude-code/issues/70336) と [#59784](https://github.com/anthropics/claude-code/issues/59784) です。 ```text API Error: 500 Internal server error. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://st
papoo.work
`Improved the Read tool to return a truncated first page with` が見えても、読み方によってはまだ落ちる
`Improved the Read tool to return a truncated first page with` が見えても、読み方によってはまだ落ちる
まず切り分けたいのは、`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
papoo.work
Error: 401 The socket connection was closed unexpectedly. Fo で止まるときにまず見るところ
Error: 401 The socket connection was closed unexpectedly. Fo で止まるときにまず見るところ
この症状は、Claude Code 側の issue 報告では 2 件とも closed になっており、しかも両方が duplicate 扱いでした。参照できる報告は [#70557](https://github.com/anthropics/claude-code/issues/70557) と [#70753](https://github.com/anthropics/claude-code/issues/70753) です。 最初に切り分けたいのは、「同じ 401 系の文面が出ているだけ」なのか、それとも「本当に会話の流れを壊しているのか」です。issue #70557 では、`.172` 以降にほぼ毎日このエラーが出るという報告があり、メッセージは `Please run /login · API Error: 401 The socket connection was closed unexpectedly. For more information, pass \`verbose: true\` in the second argument to fetch()` でし
papoo.work
`Session creation failed` が出るときに見えているのは、たぶん「古い状態が残っている」こと
`Session creation failed` が出るときに見えているのは、たぶん「古い状態が残っている」こと
この症状に近いのは、Remote Control のセッション作成が失敗し、再接続や再登録をしてもすぐには直らないケースです。報告されている issue では、iOS の Claude app から Remote Control セッションを作ろうとすると `Session creation failed — see debug log` が出る一方で、ローカル側の `claude-remote@*` systemd サービスは healthy に見えていた、と書かれています。しかも、別のマシンから新しく Remote Control セッションを登録すると、影響を受けていた環境全体で復旧したそうです。これは [#57715](https://github.com/anthropics/claude-code/issues/57715) にある報告です。 別の報告では、macOS で `claude --remote-control ketobaza` を開始したあとに Remote Control が切断され、`Session creation failed` が出たとされています。
papoo.work
The model's tool call could not be parsed (retry also failed) が出るときに見えていたこと
The model's tool call could not be parsed (retry also failed) が出るときに見えていたこと
まず、自分のケースかどうかを切り分けるなら、実行中にこの文言で止まるかを見ます。 > `The model's tool call could not be parsed (retry also failed)` 今回の症状クラスタで参照できる issue は、どちらも Claude Code 側で tool call の構造が壊れていたケースでした。[#62467](https://github.com/anthropics/claude-code/issues/62467) では、`claude-opus-4-7` と extended thinking の組み合わせで、`tool_use` ブロックが parse できずに hard-stop していたと報告されています。[#74620](https://github.com/anthropics/claude-code/issues/74620) では、Opus 4.8 の tool call で、開始タグが `court` や `call`、`count`、`caught`、`co` のような近い文字列に崩れ、harness
papoo.work
exit code 143 が出る Claude Code の切り分けメモ
exit code 143 が出る Claude Code の切り分けメモ
まず、手元の症状がこのクラスタに当てはまるかを見るなら、出方がかなり重要です。issue #62985 では、デスクトップアプリのサイドバーでセッションを切り替えただけで、動作中の `claude` プロセスが SIGTERM で止まり、`exit code 143` になっています。`Session was interrupted` の表示が出て、実行中の agent や tool call、応答途中の処理が止まる、という報告です。参照元は [#62985](https://github.com/anthropics/claude-code/issues/62985) です。 もう一つの [#62202](https://github.com/anthropics/claude-code/issues/62202) は、Desktop app と VS Code extension でだけ、ちょうど 300 秒ごとに `exit code 143` で落ちるという報告です。terminal CLI の `claude` では起きず、ラッパー側に限って再現している、と書かれています。こ
papoo.work
HTTP 404でClaude CodeがGitHubのprivate repoを読めないときに見えること
HTTP 404でClaude CodeがGitHubのprivate repoを読めないときに見えること
まず、この症状に当てはまるかを切り分けます。Issue 上では、Claude の GitHub 連携が有効になっていても、private repository にアクセスできず HTTP 404 に見える報告が出ています。たとえば [#68517](https://github.com/anthropics/claude-code/issues/68517) では、個人アカウント配下の private repo に対して Claude GitHub App を「All repositories」でも「Only select repositories」でも許可し直し、Claude 側の GitHub integration を再接続し、さらに競合しそうな custom GitHub MCP connector まで外しても、なお読めなかったと書かれています。 同じ症状として、GitHub connector は接続済みなのに、repo の追加時にファイルの読み込みや同期が失敗する、あるいは project context には載るのに個別チャットでは失敗する、という報告もありまし
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたら読むこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたら読むこと
まず、自分のケースかどうかを切り分けます。この症状は、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 の安全性確
papoo.work
`VM service not running. The service failed to start.` が出るときに見るところ
`VM service not running. The service failed to start.` が出るときに見るところ
このエラーは、少なくとも今回確認できた issue では、Cowork の VM サービス側で起動に失敗しているときに出ています。ユーザー向けの文言は同じでも、原因は 1 つではありません。 自分のケースかどうかを見分ける材料としては、まず「どの製品で出ているか」が重要です。[#39010](https://github.com/anthropics/claude-code/issues/39010) は Windows 10 Pro 上の Cowork で、起動時に `VM service not running. The service failed to start.` が出ています。報告者は、実体としては MSIX パッケージ配下の `AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\` に作られた VM 用の `rootfs.vhdx` や `smol-bin.vhdx` が NTFS 圧縮を引き継ぎ、Hyper-V が圧縮された VHDX をマウントできずに失敗していたと書いています。そこで見えていた HCS エラ
papoo.work
Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.) が出るときにまず見るところ
Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.) が出るときにまず見るところ
このエラーは、Claude の Cowork/interactive session で、隔離された Linux 環境が立ち上がらないときに出ています。少なくとも issue 報告上では、ファイル操作の機能は動くのに、shell/sandbox だけが落ちるケースがありました。 該当する報告は [#70199](https://github.com/anthropics/claude-code/issues/70199) です。 切り分けの起点はかなりはっきりしています。`Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.)` が出ていて、しかも Read/Write/Edit のようなファイル系ツールは使える。ならば、壊れているのはワークスペース全体というより、隔離 Linux 環境の起動部分だと考えるのが自然です。 別系統の issue ですが、Cowork の周辺で「内部の実行環境や受け
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに、まず疑うこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに、まず疑うこと
この症状は、GitHub issue 上では 3 件とも同じ系統のエラー文字列として報告されています。いずれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で始まり、`keys` と `messages` の数が一致していませんでした。 たとえば [#86759](https://github.com/anthropics/claude-code/issues/86759) では `keys=222 messages=221 range=[197,222)`、[#86442](https://github.com/anthropics/claude-code/issues/86442) では `keys=1139 messages=1138 range=[1078,1139)`、[#86358](https://github.com/anthropics/claude-code/issues/86358) では `keys=38 messages=37 range=[0,38)` と
papoo.work
ERR_VM_PIPE_CLOSED が出るときに見るべきところ
ERR_VM_PIPE_CLOSED が出るときに見るべきところ
この症状は、Windows 版 Claude Desktop で Cowork を起動しようとしたときに「Failed to start Claude's workspace / RPC pipe closed」と出るものです。今回参照した issue はどちらも未解決で、しかも再インストールが途中で止まる、あるいは署名検証で落ちる、という流れまで共通しています。該当する報告は [#86825](https://github.com/anthropics/claude-code/issues/86825) と [#90283](https://github.com/anthropics/claude-code/issues/90283) です。 まず、自分のケースかどうかはここで見分けやすいです。起動時に RPC pipe closed が出る一方で、VM 側のサービスは Running のまま、というパターンです。[#90283](https://github.com/anthropics/claude-code/issues/90283) では `CoworkVMService,
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のとき、まず疑うこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のとき、まず疑うこと
このエラー名がそのまま出ているなら、少なくとも「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 側のバグ
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたときに確認したこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたときに確認したこと
まず、このエラーが自分のケースかどうかを切り分けるなら、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
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず確認したいこと
この症状は、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
papoo.work
ERR_BLOCKED_BY_CLIENT が Browser pane で出るときに見ておきたいこと
ERR_BLOCKED_BY_CLIENT が Browser pane で出るときに見ておきたいこと
この症状は、Claude Code の Browser pane でトップレベルの HTML は開くのに、同一オリジンの subresource が `net::ERR_BLOCKED_BY_CLIENT` で落ちる、という形で報告されています。報告は [#86362](https://github.com/anthropics/claude-code/issues/86362) と [#89725](https://github.com/anthropics/claude-code/issues/89725) の 2 件で、どちらも「ページ自体は 200 で返るのに、CSS や JS、XHR/fetch が読めず、結果として画面が白い／素の HTML だけになる」という点が共通しています。 まず、自分のケースがこの系統かを切り分けると分かりやすいです。issue の記述で一致しているのは、次のような状況です。トップレベルの document は読み込めるのに、同じ origin の subresource だけがまとめて止まること。`http://127.0.0.1` のような li
papoo.work
Ptn: Insufficient scope: required "https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/drive.resour…"` が出るときに見えているもの
Ptn: Insufficient scope: required "https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/drive.resour…"` が出るときに見えているもの
この症状は、少なくとも 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
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の desync が出るときに見えていること
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の desync が出るときに見えていること
この症状は、Claude Code 側で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回集まっている issue は 3 件で、いずれも同じ系統のエラー文字列を含んでいました。 まず、自分のケースかどうかを見分けるには、エラー本文が `itemKeys/messages length desync` を含むかを確認します。報告されているものは、たとえば `keys=215 messages=214 range=[165,215)`、`keys=22 messages=21 range=[0,22)`、`keys=267 messages=266 range=[220,267)` でした。数は違っても、`keys` と `messages` の件数が 1 ずれている点は共通しています。 実際の issue では、エラーそのものに加えて、別の症状が同時に報告されていました。[#90169](https://github.com/anthropics/claude-
papoo.work
Error: Streamable HTTP error: Error POSTing to endpoint: {"id"... を見たら最初に確認すること
Error: Streamable HTTP error: Error POSTing to endpoint: {"id"... を見たら最初に確認すること
この症状は、Claude Code から Streamable HTTP の MCP サーバーに POST したとき、返ってきたエラー本文が `Request had insufficient authentication scopes.` になっているケースです。Issue では同じ文言が複数件まとまっており、[#70638](https://github.com/anthropics/claude-code/issues/70638)、[#70627](https://github.com/anthropics/claude-code/issues/70627)、[#82461](https://github.com/anthropics/claude-code/issues/82461) のいずれにもこのエラーが含まれていました。 まず大事なのは、これが「Claude Code 全般の操作不能」というより、MCP 接続先との認証スコープ不足として報告されている点です。コメントでも、`insufficient authentication scopes` は「streamable
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le のエラーが出たときに見えていたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages le のエラーが出たときに見えていたこと
このエラーは、少なくとも issue 上では 2 件とも open のままで、まだ解決済みの報告はありません。似た見え方でも、きっかけは少し違います。ひとつは null reference のデバッグ依頼で安全フィルタが過剰に反応したという報告、もうひとつは Anthropic API 側の HTTP 529 が出ていたという報告です。どちらも、本文に出ているエラー文字列は同じ系統でした。 まず、自分のケースかどうかを切り分けるなら、会話の途中でこの文字列が出ているかを見ます。issue #85965 では、`null` のボタンを調べてほしいという依頼で Fable 5 safeguards が「些細な理由で」発火したと書かれています。issue #84337 では「yesterday に 529 issues が複数回あった」とあり、同時に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ています。つまり、見た目は同じでも、少なくとも報告上は「安全フィルタの誤検知っぽい会話」と「
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le が出たら見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le が出たら見るところ
この症状は、少なくとも今回の 2 件の issue では、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という同じエラー文字列で報告されています。該当するのは [#89889](https://github.com/anthropics/claude-code/issues/89889) と [#89307](https://github.com/anthropics/claude-code/issues/89307) です。 まず切り分けたいのは、「Claude Code が内部でメッセージ一覧の長さ不整合を起こして落ちているのか」という点です。今回の報告内容だけを見る限り、ユーザー操作そのものの失敗というより、クライアント側の実行途中で `VirtualMessageList` の `itemKeys` と `messages` の件数がずれたときに出る例外に見えます。`keys=353 messages=352 range=[298,353)` や `keys=72 messag
papoo.work
EISDIR が出る Claude Code の2つの壊れ方
EISDIR が出る Claude Code の2つの壊れ方
まず、自分のケースかどうかを切り分けます。今回の `EISDIR` は、GitHub の報告を見る限り、少なくとも 2 系統あります。ひとつは Linux arm64 で Claude Desktop が Claude Code のバイナリを落とせず、起動のたびに「binary is missing or damaged」と出る件です [#89850](https://github.com/anthropics/claude-code/issues/89850)。もうひとつは Windows の VS Code 拡張で、`\\?\` 付きのワークスペースパスを開いたときにサイドバー復元が落ちる件です [#89775](https://github.com/anthropics/claude-code/issues/89775)。 Linux 側の症状は、報告では毎回同じです。ダウンロード対象を `open()` するところで `EINVAL: invalid argument` になり、アプリ側には次の文言が出ます。 ```text Claude Code couldn't start
papoo.work
`this is the missing part.` があるのに、指示が「取り消し」に化けるときに起きていること
`this is the missing part.` があるのに、指示が「取り消し」に化けるときに起きていること
この症状は、ユーザーが不足分を示すために `this is the missing part.` と書いたあと、別のメッセージで「まだ部品が足りない」と指摘したつもりが、Claude Code 側では「その部品をキャンセルせよ」という意味に読まれてしまうケースです。報告されている issue は [#89886](https://github.com/anthropics/claude-code/issues/89886) と [#89899](https://github.com/anthropics/claude-code/issues/89899) です。 まず見分けたいのは、単なる実装漏れではなく、モデルがユーザーの追記を逆向きに解釈していないかです。今回の issue では、ユーザーがコンポーネント仕様を渡して「this is the missing part.」と伝えたのに、その後の「a11y panel and button がない」「bottom navbar がない」といった指摘が、キャンセル指示として扱われました。[#89899](https://github.co
papoo.work
`Navigation to this domain is not allowed` が出るときに、まず疑うべきこと
`Navigation to this domain is not allowed` が出るときに、まず疑うべきこと
Claude Code の Claude in Chrome connector で、`navigate` や `computer` などの操作がすぐ失敗し、エラーが `Navigation to this domain is not allowed` になる症状が報告されています。今回の issue 群では、対象ドメインは 1 つに限られず、`mail.google.com`、`google.com`、`example.com`、`riverside.com`、`riverside.fm` まで含まれていました。つまり「特定サイトだけ弾かれる」より、承認プロンプト自体が出ないまま拒否されるケースとして読むのが近そうです。 まず切り分けたいのは、これが「そのドメイン固有の拒否」なのか、「Claude in Chrome 側でドメイン承認の状態が壊れている」のかです。報告を見る限り、後者を疑う材料が多いです。[#68891](https://github.com/anthropics/claude-code/issues/68891) では、どのドメインでも即失敗し、しかも承認プ
papoo.work
Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"} で止まるときに見えているもの
Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"} で止まるときに見えているもの
このエラーが出ているなら、少なくとも Claude Code 側では「送ろうとしたリクエストが大きすぎる」と判定されています。報告されている2件はいずれも同じ文字列で、[#73908](https://github.com/anthropics/claude-code/issues/73908) は closed、[#77419](https://github.com/anthropics/claude-code/issues/77419) は open です。現時点では、issue だけを見る限り「何がどのくらい大きかったのか」を外から確定できません。 実際の報告では、どちらもスタックの先頭に `generate` が出ています。引用するとこうです。 ```text Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}} at generate (/$bunfs/root/src/entrypoints/cli.js:12:71094) ``` 別の報
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.7.content.0: unexpected `tool_use_id` found in `advisor_tool_result` blocks と出たときに見ること
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.7.content.0: unexpected `tool_use_id` found in `advisor_tool_result` blocks と出たときに見ること
このエラーは、Claude Code 側のトランスクリプト再構築で `advisor_tool_result` と `server_tool_use` の対応が崩れたときに出ているようです。少なくとも issue 報告では、`advisor_tool_result` の前に対応する `server_tool_use` が必要なのに、それが見つからない／ずれる、という形で説明されています。 同じ症状として報告されているのは [#62885](https://github.com/anthropics/claude-code/issues/62885) と [#89348](https://github.com/anthropics/claude-code/issues/89348) です。どちらも 400 エラーの本文に `unexpected tool_use_id found in advisor_tool_result blocks` が出ています。前者では「advisor を off にしても同じエラーが出た」とあり、後者ではセッション再開ができなくなった、と報告されています。ど
papoo.work
`ERR_CONNECTION_RESET` が出るとき、まず見るべき切り分け
`ERR_CONNECTION_RESET` が出るとき、まず見るべき切り分け
この症状は、Claude Code の cloud environment や web sandbox でブラウザ系の通信だけが落ちるときに出ています。報告されているのは、Playwright MCP の `browser_navigate` や headless Chromium の `page.goto()` が、どの URL でも `net::ERR_CONNECTION_RESET` になるケースです。対象は `https://example.com` や `www.google.com` のような一般的なサイトでも同じでした。いっぽうで、同じセッション・同じシェル内では `curl` や Node の `fetch`、`https` モジュールが成功している、というのが共通点です。これは [#85757](https://github.com/anthropics/claude-code/issues/85757) と [#73564](https://github.com/anthropics/claude-code/issues/73564) に書かれている症状です。 自
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の症状を見分ける
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の症状を見分ける
まず、自分のケースかどうかを切り分けます。今回の症状は、Claude Code の画面やログで `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文言が出るものです。報告されている 2 件の issue は、どちらもこのエラー文字列を伴っていました。([#89631](https://github.com/anthropics/claude-code/issues/89631), [#89615](https://github.com/anthropics/claude-code/issues/89615)) ひとつ目の報告では、scaling issue を解こうとしていたら Fable 5 が誤ってフラグを立てた、と書かれています。もうひとつは、組織の monthly spend limit の表示が daily limit の状況と食い違っていて、`/usage-credits` を促す文言が出た、という内容です。つまり、少なくともこの issue 群では、まったく同じエラー表
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の件で、まず自分の症状かを見分ける
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の件で、まず自分の症状かを見分ける
この症状は、Issue に載っているエラーメッセージがかなり特徴的です。検索用にそのまま書くと、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` です。 手元で確認できたのは、少なくとも次の 2 件の報告が同じクラスタに入っていることです。どちらも open のままで、解決済みの報告ではありません。 どちらの issue でも、報告されたエラーは同じ形です。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=1340 messages=1339 range=[1307,1340)) at kQS (B:/~BUN/root/src/entrypoints/cli.js:23006:8181) at Yrm (B:/~BUN/root ``` ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages
papoo.work
`Error: Streamable HTTP error: Error POSTing to endpoint: {"t` で止まるときにまず見ること
`Error: Streamable HTTP error: Error POSTing to endpoint: {"t` で止まるときにまず見ること
この症状で報告されているのは、Claude Code が MCP server への POST に失敗し、返ってきた応答が `403 Forbidden` になっているケースです。手元で確認できた issue はどちらも同じ断片を含んでいました。 ```text Error: Streamable HTTP error: Error POSTing to endpoint: {"type":"error","error":{"type":"permission_error","message":"MCP server returned 403 Forbidden. The request may have been blocked by a firewal ``` ```text Error: Streamable HTTP error: Error POSTing to endpoint: {"type":"error","error":{"type":"permission_error","message":"MCP server returned 403 Forbidden. T
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出たときに確認したいこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出たときに確認したいこと
この症状は、Issue 上では少なくとも 2 件まとまっていて、どちらも未解決です。[#85847](https://github.com/anthropics/claude-code/issues/85847) は legacy codebase の reverse engineering 中に fallback model のメッセージが出たあと、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=36 messages=35 range=[0,36))` に落ちています。[#87169](https://github.com/anthropics/claude-code/issues/87169) でも、通常で安全なプロンプトだと報告されているセッションで同系統のエラーが出ており、`keys=50 messages=49 range=[0,50)` というズレが記録されています。 まず、この文字列が見えていて、しかも途中でセッションが不自然に止まるなら、同じ症状クラスタの可能
papoo.work
`TypeError: Cannot destructure property 'preloadScripts' of '` が出るときに見るべきこと
`TypeError: Cannot destructure property 'preloadScripts' of '` が出るときに見るべきこと
この症状は、少なくとも今回参照した 2 件の issue では、Claude Desktop の起動直後に落ちる系の話として報告されています。1 件は Windows/MSIX 版で、起動後 1.5〜10 秒ほどで main process が自分で終了し、`exit code -1 (0xFFFFFFFF)` になったというものです [#86535](https://github.com/anthropics/claude-code/issues/86535)。もう 1 件は Windows 版で、renderer の bootstrap 周りや sessions-bridge、`claude.exe` の子プロセスに関する不調が並んでいます [#79846](https://github.com/anthropics/claude-code/issues/79846)。 ただし、手元で確認できている一次情報は Windows ではありません。実際に取得できたのは Linux 上の Node.js バージョンだけです。 ```text $ node --version v16.15.
papoo.work
`auto-update failed` が消えないときに見たこと
`auto-update failed` が消えないときに見たこと
`auto-update failed` の表示が出ても、実際には壊れていないケースがあります。少なくとも issue [#82408](https://github.com/anthropics/claude-code/issues/82408) と [#89286](https://github.com/anthropics/claude-code/issues/89286) では、背景の自動更新が一度失敗したあと、その失敗表示が残り続ける挙動が報告されています。しかも `claude doctor` を実行しても「No installation issues found」と返り、表示されている警告と実態が一致しません。 読者がまず確認したいのは、今見えている `auto-update failed` が「本当に更新失敗中」なのか、「過去の失敗記録が残っているだけ」なのかです。issue の報告を見る限り、この切り分けが重要です。[#82408](https://github.com/anthropics/claude-code/issues/82408) では、失敗時の状態が `
papoo.work
`Claude Code returned an error result: No conversation found with session ID` が出るときに、まず見るところ
`Claude Code returned an error result: No conversation found with session ID` が出るときに、まず見るところ
このエラーを追っていくと、少なくとも issue 上では「どのセッションを開こうとしているか」で挙動が分かれています。 `[#61726](https://github.com/anthropics/claude-code/issues/61726)` では、Cursor の Claude Code extension で Web タブに並んだセッションをクリックすると失敗し、Local タブのセッションは開ける、と報告されています。 `[#79924](https://github.com/anthropics/claude-code/issues/79924)` では、VS Code extension の `/memory` パネルで refresh を押したときに、同じ文言のエラーが出ています。 `[#85892](https://github.com/anthropics/claude-code/issues/85892)` では、VS Code extension が閉じられて再度開かれるたびに、空の local session stub が増えていく現象が
papoo.work
`Tool execution failed` が出るとき、まず見るべき切り分け
`Tool execution failed` が出るとき、まず見るべき切り分け
`Tool execution failed` という表示だけでは、原因は1つに絞れません。今回確認できた issue 報告では、少なくとも次の2種類が混ざっています。ひとつは、MCP サーバーに tool 呼び出し自体が届いていないケース。もうひとつは、特定の tool だけが失敗するケースです。 たとえば [#79926](https://github.com/anthropics/claude-code/issues/79926) では、Claude Desktop のローカル stdio MCP サーバーで `initialize` と `tools/list` は通るのに、`tools/call` がサーバーの stdin に一切書かれないと報告されています。画面上は `Tool execution failed` あるいは `Failed to call tool` になります。一方で、同じ症状群の [#69642](https://github.com/anthropics/claude-code/issues/69642) では Gmail MCP の `search_
papoo.work
`claude native binary not installed.` が出るときにまず見るところ
`claude native binary not installed.` が出るときにまず見るところ
この症状は、少なくとも報告されている範囲では Termux / Android と、macOS 上での npm グローバルインストールまわりの2系統に分かれていました。どちらも、`claude` を起動したときに 「native binary が見つからない」 形で止まります。ただし、解決済みの共通パターンはまだ見えていません。 Android 側の報告は [#50270](https://github.com/anthropics/claude-code/issues/50270) です。ここでは、v2.1.113 以降で Claude Code が JavaScript のエントリポイントから glibc のネイティブ Linux バイナリに切り替わり、Termux では動かなくなったと書かれています。報告者は、v2.1.112 は動くが v2.1.113 と v2.1.114 は壊れると述べています。 macOS 側の報告は [#84224](https://github.com/anthropics/claude-code/issues/84224) です。こちらは別の
papoo.work
`claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now` が出たときに見えていること
`claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now` が出たときに見えていること
この文字列が出ているなら、少なくとも今の Claude Code は「auto mode で Bash の安全判定をしたいが、`claude-opus-4-8` が一時的に使えない」と判断しています。ここで大事なのは、エラーそのものよりも、Bash の扱いが auto mode による安全判定待ちで止まるという点です。 ただし、原因が一つに決まるわけではありません。公開 issue では、長いセッションやコンテキスト圧縮のあとにモデルが不自然な出力をした報告と、`ANTHROPIC_BASE_URL` 配下で auto-mode の safety classifier がその endpoint に向くという報告が別々に出ています。前者は [#74136](https://github.com/anthropics/claude-code/issues/74136)、後者は [#78372](https://github.com/anthropics/claude-code/issues/78372) です。どちらも、少なくとも「auto mode の内部で何かがうまくいっていな
papoo.work
`jq` がないと valid JSON を invalid 扱いする
`jq` がないと valid JSON を invalid 扱いする
この症状は、Claude Code の hook 開発用スクリプト `plugin-dev/skills/hook-development/scripts/test-hook.sh` を使っていて、入力 JSON は正しいはずなのに「invalid JSON」と言われるケースです。issue [#83802](https://github.com/anthropics/claude-code/issues/83802) では、`jq` がインストールされていない環境でこの誤判定が起きると報告されています。 まず切り分けたいのは、入力そのものが壊れているのか、それとも `jq` の不足が原因なのか、です。報告内容では、`jq` がないと次の判定が走ります。 ```bash if ! jq empty "$TEST_INPUT" 2>/dev/null; then echo "❌ Error: Test input is not valid JSON" ``` `2>/dev/null` によって `jq: command not found` が捨てられるため、コマンドが見つからない場合
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたら、まず見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたら、まず見るところ
このエラー文字列が出ているなら、少なくとも報告されている症状群は同じです。Issue では [#87283](https://github.com/anthropics/claude-code/issues/87283) と [#88158](https://github.com/anthropics/claude-code/issues/88158) の 2 件で、どちらも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が添えられていました。前者は「最初に当たったものだけを見て止まる」「十分に確認しない」といった挙動、後者は `update_document` の patch mode が checkbox list の後ろの内容を静かに落とす、という報告です。 ただし、どちらの issue も解決済みではありませんでした。代表 issue 側に付いていたコメントは、再現手順がまだ必要で、必要なら新しい issue を開いてほしいという趣旨でした。つまり、現時点では「これで直る」と言
papoo.work
ERR_ABORTED が出るときに、まず見るべき 2 つの Claude Code 事例
ERR_ABORTED が出るときに、まず見るべき 2 つの Claude Code 事例
`ERR_ABORTED` は同じ文字列でも、報告されている中身がかなり違います。今回の issue 群では、少なくとも 2 パターンありました。ひとつは Claude Cowork 連携で artifact を作った直後に表示と共有が失敗する件、もうひとつは Claude in Chrome の `read_network_requests` が中断された通信に対して HTTP 503 を作って見せてしまう件です。 自分のケースかどうかを先に見分けるなら、最初にこの 2 点を切り分けるのが早いです。artifact 作成直後に失敗しているなら [#61571](https://github.com/anthropics/claude-code/issues/61571) に近いです。ネットワークの読み取り結果として 503 が返ってくるなら [#77841](https://github.com/anthropics/claude-code/issues/77841) に近いです。 この issue は closed ですが、本文にある通り「artifact 生成直後に表示できない」
papoo.work
`Error: 401 {"type":"error","error":{"type":"authentication_e` で止まるときに見ること
`Error: 401 {"type":"error","error":{"type":"authentication_e` で止まるときに見ること
そのエラーが出ていて、Claude Code の操作が途中で止まるなら、この件の報告とかなり近い可能性があります。Issue の本文では、ツールが指示に従わない、独自判断を始める、といった見え方で困っていましたが、実際に載っているエラーは同じでした。 引用できる一次情報は、報告されたエラー文字列です。 ```text Error: 401 {"type":"error","error":{"type":"authentication_error","message":"Invalid authentication credentials"},"request_id":"req_011CbsmtzJamMBn7jbsWoJnJ"} ``` 同じ症状として挙がっていた issue は [#68571](https://github.com/anthropics/claude-code/issues/68571) と [#68427](https://github.com/anthropics/claude-code/issues/68427) です。どちらも closed で、代表 iss
papoo.work
The socket connection was closed unexpectedly. For more info が出るときに見ておきたいこと
The socket connection was closed unexpectedly. For more info が出るときに見ておきたいこと
この症状は、少なくとも今回渡された 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`
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の文字列が出たら、まず見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の文字列が出たら、まず見るところ
この症状は、GitHub Issue 上では少なくとも 2 件まとまっていて、どちらも `[open]` のままで解決済みではありません。報告されているエラーは同じで、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` です。 該当 issue は [#80676](https://github.com/anthropics/claude-code/issues/80676) と [#80664](https://github.com/anthropics/claude-code/issues/80664) です。 まず、自分のケースかどうかを切り分けます。issue の内容を見ると、単純な表示崩れというより、会話履歴の扱いとモデル側の応答の整合がずれたときに出ているように見えます。`#80676` では FIDO 設定の支援をモデルが拒んだと報告され、`#80664` では 1 回の planning タスクの途中でモデルが切り替わったことに困惑している、と書かれています。どちらの報告にも
papoo.work
`Permission for this action was denied by the Claude Code aut` と出るときに見分けたいこと
`Permission for this action was denied by the Claude Code aut` と出るときに見分けたいこと
この症状は、少なくとも報告上は 2 つの別パターンがあります。ひとつは、auto mode の判定が本来通してよいツール呼び出しを止めるケース。もうひとつは、コンパクション後の文脈を「まだ有効なユーザー指示」とみなしてしまい、その後の呼び出しを拒むケースです。いずれも、ユーザー操作そのものが禁止されているというより、Claude Code 側の自動判定が原因になっています。 まず切り分けの軸は、拒否が「どの場面で」出たかです。長いセッションの途中で自動コンパクションが入った直後なら [#77158](https://github.com/anthropics/claude-code/issues/77158) の報告に近いです。ここでは、auto-mode の safety classifier がコンパクション時の割り込み文を恒久的な指示として扱い、次の正当な tool call を拒否したとされています。報告本文では、`--permission-mode auto` の環境、`claude-opus-4-8` と `claude-fable-5` の両方で再現したと書かれています。
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で止まるときに見るもの
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で止まるときに見るもの
この症状は、報告されている範囲では `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で、`keys=174 messages=173` や `keys=473 messages=472` のように、`itemKeys` と `messages` の数が 1 件ずれて落ちています。少なくとも issue [#88908](https://github.com/anthropics/claude-code/issues/88908) と [#88227](https://github.com/anthropics/claude-code/issues/88227) では、同じエラー文字列が出ています。 まず自分のケースかどうかを見るなら、エラーメッセージの中に `VirtualMessageList` と `length desync` が含まれているかを確認します。さらに、スタックトレースに `lGE` や `i8h` が見えていれば、報告された症状と一致しています。`TelemetryS
papoo.work
`Cannot find module '/Users/uditgoenka/Desktop/workspace/social/.claude/hooks/session-state.cjs'` が出るときに見るところ
`Cannot find module '/Users/uditgoenka/Desktop/workspace/social/.claude/hooks/session-state.cjs'` が出るときに見るところ
この症状は、Claude Code のフック実行時に `MODULE_NOT_FOUND` が出て、`session-state.cjs` を探しに行って失敗しているケースです。少なくとも issue [#54743](https://github.com/anthropics/claude-code/issues/54743) では、`PreToolUse:Bash`、`PreToolUse:Read`、`PostToolUse:Bash`、stop hook など複数の hook event で同じエラーが連発し、出力を埋め尽くすが、処理自体はブロックされないと報告されています。 手元で確認できた範囲では、`settings.json` のキー構造は次の状態でした。値は取れていませんが、少なくとも今回の検証環境では該当ファイルが見つかっていません。 ```text ~/.claude/settings.json: (存在しない) /mnt/vda5/git/papoo/newsbot_openai/.claude/settings.json: (存在しない) /mnt/vda5/g
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ['reddit.com']. Read m と出たときに起きていたこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ['reddit.com']. Read m と出たときに起きていたこと
このエラー文字列が見えていて、Claude Code の動きが不自然に増える、あるいは作業中にモデルが変わったように見えるなら、今回集めた issue 群とかなり近いです。対象になっているのは [#68961](https://github.com/anthropics/claude-code/issues/68961) と [#78780](https://github.com/anthropics/claude-code/issues/78780) です。どちらも報告時に、同じエラー文として `Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ['reddit.com']. Read more: ...` が添えられていました。 まず見分けたいのは、単発の失敗ではなく、同じエラーが続けて出ているかどうかです。[#68961](https://github.co
papoo.work
`VM connection timeout after 60 seconds` が出るときに、まず見たいところ
`VM connection timeout after 60 seconds` が出るときに、まず見たいところ
この症状は、少なくとも 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
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の症状が出たときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の症状が出たときに確認したいこと
この症状は、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文言で報告されています。今回見つかった 3 件の issue は、いずれも open のままで、解決済みは 0 件でした。こちらで確認できた範囲では、まだ「これをやれば直る」と言い切れる情報はありません。 まず、自分のケースかどうかを見分けるなら、エラー本文がどれかに一致するかを見ます。今回の issue では、少なくとも次の形が繰り返し出ています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=1070 messages=1069 range=[1013,1070)) at A_b (B:/~BUN/root/src/entrypoints/cli.js:14712:8188) at f8p (B:/~BUN/root/src/ ``` 別の報告でも、`keys` と `messages` の数が
papoo.work
Error: 404 {"type":"error","error":{"type":"not_found_error"… が出て Claude Fable 5 が使えないときに確認したこと
Error: 404 {"type":"error","error":{"type":"not_found_error"… が出て Claude Fable 5 が使えないときに確認したこと
この症状は、`not_found_error` の本文に `Claude Fable 5 is not available. Please use Opus 4.8.` と出ているのが手がかりです。報告された issue では、[#68683](https://github.com/anthropics/claude-code/issues/68683) と [#68735](https://github.com/anthropics/claude-code/issues/68735) のどちらも同じエラー文字列でした。どちらも closed になっており、代表 issue 側では重複候補の案内も出ています。 実際の報告文に含まれていたエラーは、少なくとも次の形でした。 ```text Error: 404 {"type":"error","error":{"type":"not_found_error","message":"Claude Fable 5 is not available. Please use Opus 4.8. Learn more: https://ww
papoo.work
This version can't be shared publicly が出るときに見えていること
This version can't be shared publicly が出るときに見えていること
「Share publicly」に切り替えた直後に、`This version can't be shared publicly. Publish a new version or change the shared version, then try again.` が返る。これが出ているなら、少なくとも issue 報告上は、Artifact の公開共有がその版で止まっている状態です。[#79824](https://github.com/anthropics/claude-code/issues/79824) では、Markdown の Artifact を公開しようとしてこの文言が即座に出ています。[#78374](https://github.com/anthropics/claude-code/issues/78374) でも、別の Artifact で同系統の共有エラーが報告されています。 この症状でまず大事なのは、単発の失敗ではなく、再公開しても続くかどうかです。[#79824](https://github.com/anthropics/claude-code/iss
papoo.work
Claude Code が `exit code 3` で落ちるときに見えていること
Claude Code が `exit code 3` で落ちるときに見えていること
自分のケースかどうかを先に切り分けるなら、今回集められている issue はどれも「Claude Code のプロセスが途中で死んで、結果として `exited with code 3` と見える」点は共通です。ただし、落ちるタイミングと見えているクラッシュ住所が違います。 たとえば、[#78436](https://github.com/anthropics/claude-code/issues/78436) は、Windows 11 上の Claude Code desktop session が約 30 分後に死んだ報告です。本文では `Elapsed: 1817103ms` とあり、Bundled された `claude.exe` が次のように panic しています。 ```text panic(main thread): Segmentation fault at address 0xFFFFFFFFFFFFFFFF ``` この issue の報告では、「起動直後ではなく、セッションがしばらく動いたあとに落ちた」点がはっきりしています。しかも、同じ `0xFFFFFFFF
papoo.work
`disabled after repeated failures · restart to retry` が出るときに見えていること
`disabled after repeated failures · restart to retry` が出るときに見えていること
まず、この症状に当てはまるかどうかを先に切り分けます。今回の issue では、Remote Control が失敗を重ねたあとに無効化され、再起動しないと試し直せないように見える、という報告が 2 件あります。`[#78364](https://github.com/anthropics/claude-code/issues/78364)` では「3 回の一時的な失敗」で Remote Control が静かに恒久無効化される、と書かれています。`[#87269](https://github.com/anthropics/claude-code/issues/87269)` では、起動時に Remote Control の開始に失敗すると、そのセッション中は回復せず、再接続経路もないと報告されています。 今回の手元の確認では、Claude Code は Remote Control 機能自体を案内していますが、同時に複数インストールの存在も出ています。実際の出力は次のとおりです。 ```text $ claude --version 2.1.207 (Claude Code) ``
papoo.work
`Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ...` が出るときに見えること
`Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ...` が出るときに見えること
この症状は、Claude Code が何かの処理で外部ドメインにアクセスしようとして、そのドメインが user agent から到達できないと返されたときに出ています。今回の issue 群では、報告されているドメインが少し違います。[#78780](https://github.com/anthropics/claude-code/issues/78780) では `reddit.com`、[#76310](https://github.com/anthropics/claude-code/issues/76310) では `blog.naver.com` と `m.blog.naver.com` が挙がっていました。 手元で確認できたのは、Claude Code CLI の表示と `claude agents --help` までです。少なくともこの環境では、`claude agents` はバックグラウンドエージェント管理のコマンドとして存在していました。 ```text $ claude --version 2.1.207 (Claude Code) ``` ```text $
papoo.work
`Permission for this action was denied by the Claude Code auto mode classifier.` が出て、通るはずの操作まで止まるとき
`Permission for this action was denied by the Claude Code auto mode classifier.` が出て、通るはずの操作まで止まるとき
この症状に当てはまるかどうかは、かなりはっきりしています。Claude Code の auto permission mode で、ユーザーが止めるつもりのない通常のツール呼び出しまで `Permission for this action was denied by the Claude Code auto mode classifier.` で落ちる。しかも、その理由が「直前のコンパクション時の文言」や、ユーザーが明示した許可に引っ張られているように見える、という報告です。 Issue [#77158](https://github.com/anthropics/claude-code/issues/77158) では、auto-compaction が走ったあと、コンパクション用の割り込み文の `Do NOT call any tools` を「まだ有効なユーザー境界」とみなして、その後の正当な tool call を拒否したと書かれています。報告者は `autoCompactWindow` に達した長いセッションで再現し、`claude-opus-4-8` と `claude-
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の症状に当たるかどうか
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の症状に当たるかどうか
この件は、Claude Code の画面や処理中に ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=60 messages=59 range=[0,60)) ``` のようなエラーが出るケースです。報告されている issue は 2 件で、[#88174](https://github.com/anthropics/claude-code/issues/88174) は closed、[#87911](https://github.com/anthropics/claude-code/issues/87911) は open でした。どちらも同じ系統のメッセージを含んでいます。 まず、筆者の環境で確認できた範囲では、Claude Code CLI は 2.1.207 でした。`claude doctor` では複数インストールが見つかっています。ここは実際の出力をそのまま載せます。 ```text $ claude --version 2.1.207 (Claud
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出たときに確認したいこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出たときに確認したいこと
この症状は、少なくとも今回集めた issue では「Claude Code の実行中に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出る」という形で報告されています。 検索しやすいようにエラー文字列をそのまま書くと、`keys=17 messages=16 range=[0,17)` のように、`itemKeys` と `messages` の件数がずれている例と、`keys=109 messages=108 range=[66,109)` のように別の件数で出ている例がありました。いずれも同じ症状クラスタとして集まっています。 まず、自分のケースかどうかは「Claude Code の内部エラーとしてこの文字列が出ているか」で切り分けるのがよさそうです。今回の報告に出ているのは、ユーザーのコマンド失敗というより、`VirtualMessageList` の整合性が崩れたと見えるエラーです。少なくとも issue の本文からは、Shell の PATH 変更のような別の機能不具合と直
papoo.work
`Tool execution failed` が出るとき、まず見るべきこと
`Tool execution failed` が出るとき、まず見るべきこと
自分のケースかどうかは、かなりはっきりしています。少なくとも issue 報告では、Claude Desktop / Claude Code 側で MCP の tool call が失敗し、相手のサーバーに届いていない例が出ています。 一方で、同じサーバー上でも `outputSchema` を持たないツールは正常に動く、と書かれています。 手元で確認できた範囲では、Claude Code CLI 自体は入っています。 ```text $ claude --version 2.1.207 (Claude Code) ``` MCP 関連のサブコマンドもあります。 ```text $ claude mcp --help Usage: claude mcp [options] [command] Configure and manage MCP servers Options: -h, --help Display help for command Commands: add [options] <name> <commandOrUrl
papoo.work
hook_non_blocking_error が Windows で出るときに見ておきたいこと
hook_non_blocking_error が Windows で出るときに見ておきたいこと
まず、この症状は「Claude Code の hook が関係しているらしいが、処理自体は止まらない」タイプではなく、少なくとも issue 上ではもっと厄介に見えます。Windows 環境で `hook_non_blocking_error` が繰り返し出て、設定した hook コマンドが実行されていないように見える、という報告が上がっています。 報告は 2 件あり、どちらも Windows 上の Claude Code に関するものです。[#72636](https://github.com/anthropics/claude-code/issues/72636) では「configured hook commands を実行しない。hook runner が `git` を呼んで失敗を黙って飲み込む」と書かれています。[#79847](https://github.com/anthropics/claude-code/issues/79847) では、Windows で `fg: no job control` が `hook_non_blocking_error` として再発し
papoo.work
`advisor_tool_result_error` で advisor が `unavailable` になるときに見ておくこと
`advisor_tool_result_error` で advisor が `unavailable` になるときに見ておくこと
この症状は、advisor 呼び出しの結果が `advisor_tool_result_error` として返り、エラーコードが `unavailable` になるものです。手元で確認できた issue はどちらも「advisor を使うと落ちる」が共通していますが、発生条件は少し違います。 まず切り分けたいのは、あなたのケースが「Fable 5 を advisor にしたときだけ不安定」なのか、「セッションが重くなると advisor 自体が死ぬ」のかです。前者なら [#75971](https://github.com/anthropics/claude-code/issues/75971) に近く、後者なら [#76049](https://github.com/anthropics/claude-code/issues/76049) に近いです。 手元の環境では `claude doctor` は大きな破損を示していませんでした。出力はこうです。 ```text $ claude doctor Claude Code doctor Running: native (2.1.20
papoo.work
Claude Desktop の Code タブが `exit code 127` で落ちるときに見ておくこと
Claude Desktop の Code タブが `exit code 127` で落ちるときに見ておくこと
自分のケースかどうかを先に切り分けるなら、Claude Desktop の通常チャットは動くのに、Code タブだけが起動直後に失敗するかどうかです。Issue [#83656](https://github.com/anthropics/claude-code/issues/83656) と [#82587](https://github.com/anthropics/claude-code/issues/82587) では、どちらも Code タブの起動失敗が報告されていて、エラー文に `Malformed Mach-o file` と `exit code 127` が出ています。前者では、Desktop が別途ダウンロードした `claude` バイナリの署名状態まで確認されています。 今回の issue 群で見えているのは、少なくとも「Claude Code 自体の機能不全」というより、Claude Desktop 側が起動する `claude` バイナリの読み込みに失敗している、という形です。`#83656` の報告では、main の Claude.app 本体と help
papoo.work
`Auto-update failed` が消えないときに見ること
`Auto-update failed` が消えないときに見ること
まず、自分のケースかどうかはかなり絞れます。`claude doctor` に `Auto-update failed` 相当の履歴が残り続け、しかも `Last update attempt: failed` のような表示が消えないなら、今回の症状クラスタに近いです。Issue では、更新チェックや一時的なネットワーク断をきっかけに失敗状態が記録され、その後の起動や再接続、`claude update`、`/doctor` でも自動では消えない報告がありました。 関係する報告は [#70608](https://github.com/anthropics/claude-code/issues/70608) と [#65093](https://github.com/anthropics/claude-code/issues/65093) です。前者は `~/.claude/.last-update-result.json` に入った失敗状態がその後の成功で上書きされない、という内容でした。後者は Windows でセッション中にネットワークが落ちたあと、`Auto-update fa
papoo.work
`The advisor tool is unavailable. Do not try to use it again.` が出て advisor が戻らないときに見えたこと
`The advisor tool is unavailable. Do not try to use it again.` が出て advisor が戻らないときに見えたこと
この症状は、advisor の呼び出しがセッション中に一度成功したあと、同じセッション内で突然 > `The advisor tool is unavailable. Do not try to use it again.` に変わり、その後は advisor を実質的に使えなくなる、という形で報告されています。issue [#77513](https://github.com/anthropics/claude-code/issues/77513) では、セッション序盤の `advisor()` は成功したのに、後半でこのエラーになり、理由が出ないままだったと書かれています。issue [#67306](https://github.com/anthropics/claude-code/issues/67306) でも、最初の呼び出しで同じ文言が返り、その後は「do not try again」の通りセッション中ずっと戻らなかったとあります。 まず、自分のケースかどうかを見分けるなら、次の2点です。ひとつは、advisor が「そのセッションでは最初は動いていたか」。もうひとつは、失
papoo.work
exit code 143 が出るときにまず疑うこと
exit code 143 が出るときにまず疑うこと
`exit code 143` は、この材料だけを見ると「Claude Code のプロセスが SIGTERM で終わった」系の症状として扱うのが自然です。そう見てよさそうな根拠は、issue 側で実際に `SIGTERM (exit 143)` と書かれていることです。たとえば [#87658](https://github.com/anthropics/claude-code/issues/87658) では、Claude desktop アプリ内で 2 つ目の local Code セッションを始めると、先に動いていた CLI プロセスが SIGTERM で終了すると報告されています。 ただし、同じ `exit code 143` でも原因はひとつではありません。#76293 では、対話中の Claude Code が Bash tool の成功後に何のエラー表示もなく shell に戻り、あとでセッションを再開できたと書かれています。こちらの報告では、約 3 日動作していたこと、永続化された transcript が約 4.6 MB だったこと、request metadata
papoo.work
`Error: 404 {"type":"error","error":{"type":"not_found_error"` が出て、Claude Fable 5 が使えないと返ってくるときに確認したこと
`Error: 404 {"type":"error","error":{"type":"not_found_error"` が出て、Claude Fable 5 が使えないと返ってくるときに確認したこと
この症状は、Claude Code がリクエスト先から ```text Error: 404 {"type":"error","error":{"type":"not_found_error","message":"Claude Fable 5 is not available. Please use Opus 4.8. Learn more: https://www.anthropic.com/news/fable-mythos-access"}} ``` を受け取って止まるケースです。issue 群では同じ文言が繰り返し報告されていました。たとえば [#68290](https://github.com/anthropics/claude-code/issues/68290)、[#68381](https://github.com/anthropics/claude-code/issues/68381)、[#68188](https://github.com/anthropics/claude-code/issues/68188)、[#76316](https://github.c
papoo.work
`Error: ELOOP: too many symbolic links encountered, open '/pr` で止まるときに見えているもの
`Error: ELOOP: too many symbolic links encountered, open '/pr` で止まるときに見えているもの
この症状は、issue [#87609](https://github.com/anthropics/claude-code/issues/87609) と [#87606](https://github.com/anthropics/claude-code/issues/87606) で、どちらも同じ系統のエラーとして報告されています。報告本文では、Claude 側の表示として > `API Error: Opus 4.8 can't help with this. Start a new session to continue.` に続いて、 > `Error: ELOOP: too many symbolic links encountered, open '/private/tmp/claude-503/-Users-b59c0877-f27c-4f84-86cf-511dc2fe8180-Documents-Jarvis--projects-competition-module/6cab9d6c-1a11-4c7c-9da5-3feec...` というエラーが出ています。少な
papoo.work
String to replace not found が出るときに、まず確認したいこと
String to replace not found が出るときに、まず確認したいこと
この症状クラスタでは、見えている失敗が 2 つあります。ひとつは、`Edit` や `Write` が「置換対象の文字列が見つからない」と扱われる系の失敗。もうひとつは、YAML の前提が崩れたときに、別の内容まで巻き込んで壊れるケースです。手元で確認できた情報だけでいうと、少なくとも [#76868](https://github.com/anthropics/claude-code/issues/76868) では、Markdown ファイルの frontmatter が YAML として解釈できないときに、内容をそのまま残すのではなく空の stub に差し替えてしまう、という報告がありました。なお [#87643](https://github.com/anthropics/claude-code/issues/87643) は open で、`isolation:"worktree"` の subagent が親セッション側の worktree に書き込んでしまう、という別系統の報告です。 最初に切り分けたいのは、「自分が遭遇しているのが、文字列置換の失敗なのか」「それとも別の
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに見えていたもの
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに見えていたもの
この件は、まず「自分のケースかどうか」を切り分けるのが先です。報告されているのは、同じエラー文字列を含む 2 件の issue で、どちらも Opus 5 の安全フィルタまわりで誤検知が起きた、という内容でした。 両方に出ているエラーは同じです。 ```text 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` の件数がずれている、という内部不整合に見えます。ただし、issue の本文から読み取れる範囲では、最終的に「CLI の一般的な壊れ方」なのか「Opus 5 の安全スキャン経由で出る誤検知」なのかは切り分けきれません。少なくとも、報告者は同じエラーを、連続リクエスト時の誤
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたときの切り分け
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたときの切り分け
このエラーは、今回集まっている 4 件の issue ではいずれも同じ文言で報告されています。本文だけを見る限り、個別の操作に埋もれた別件というより、Claude Code 側の表示・内部状態の不整合に触れている可能性があります。ただし、現時点で確認できるのは「そう報告されている」という事実までです。根本原因は分かっていません。 まず自分のケースかどうかを確かめるなら、表示される文言がこの形かを見ます。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=87 messages=86 range=[0,87)) TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=106 messages=105 range=[70,106)) TelemetrySafeError: VirtualMessageList: itemKeys/messages length desyn
papoo.work
`claude native binary not installed.` が出るときに見るところ
`claude native binary not installed.` が出るときに見るところ
このエラーは、少なくとも今回の 2 件の issue では、`claude` を起動したときに「native binary が見つからない」と言われる症状でした。ひとつは `npm i @anthropic-ai/claude-code@2.1.126` の直後に `claude` を実行して発生し、もうひとつは自動更新が成功扱いになったあと、次の起動で同じエラーになっています。参照した issue は [#57577](https://github.com/anthropics/claude-code/issues/57577) と [#85974](https://github.com/anthropics/claude-code/issues/85974) です。 手元で確認した環境でも、`claude doctor` はインストール状態に少し気になる点を出しています。`native` で動いている一方で、`npm-global` の残骸も見えていました。 ```text $ claude doctor Claude Code doctor Running: native (2.
papoo.work
`ERR_BLOCKED_BY_CLIENT` が Browser pane で出るときに見えているもの
`ERR_BLOCKED_BY_CLIENT` が Browser pane で出るときに見えているもの
まず切り分けたいのは、Claude Code の Browser pane で開いているページが「HTML は返るのに、CSS や JS などの subresource だけが落ちる」状態かどうかです。今回の issue 報告では、トップレベルの document は読み込める一方で、同一オリジンの subresource が `net::ERR_BLOCKED_BY_CLIENT` になり、画面が真っ白、あるいはスタイルの当たっていない素の HTML だけが見える、という症状が共通しています。対象は `mcp__Claude_Browser__*` / preview pane で、Claude in Chrome 拡張ではないと明記されています。 報告の中身は少しずつ違いますが、少なくとも次の2系統は同じ症状クラスタとしてまとまっています。 筆者側で実際に確認できた Claude Code の状態は次のとおりです。 ```text $ claude --version 2.1.207 (Claude Code) ``` ```text $ claude doctor Cla
papoo.work
`Navigation to this domain is not allowed` が出るとき、まず見るべき切り分け
`Navigation to this domain is not allowed` が出るとき、まず見るべき切り分け
この症状は、issue の内容を見る限り「Claude in Chrome / Claude Code の MCP 経由で `navigate` を呼ぶと、許可済みのはずのドメインでも即座に拒否される」ケースが中心です。少なくとも報告されている範囲では、承認プロンプトが出ないまま `Navigation to this domain is not allowed` で止まっています。 たとえば [#58464](https://github.com/anthropics/claude-code/issues/58464) では、Claude in Chrome の設定で `Your approved sites` に入っていて、拡張機能のサイトアクセスも `On all sites` なのに、`mcp__Claude_in_Chrome__navigate` がそのドメインを拒否したと報告されています。手動で Chrome 上では普通に開けるのに、MCP 経由だけ失敗する、という切り分けです。 筆者の環境では Claude Code CLI の存在と MCP 管理コマンドの有無までは確
papoo.work
The socket connection was closed unexpectedly. For more info が出るときに見えていたこと
The socket connection was closed unexpectedly. For more info が出るときに見えていたこと
この症状は、issue 報告上では [#65202](https://github.com/anthropics/claude-code/issues/65202) と [#59781](https://github.com/anthropics/claude-code/issues/59781) で確認できます。どちらも、CLI の操作中に `The socket connection was closed unexpectedly. For more information, pass \`verbose: true\` in the second argument to fetch()` という文言が出ています。少なくとも報告された範囲では、単独のローカル設定ミスというより、通信が途中で切れたときに見えるエラーとして扱われています。 最初に切り分けたいのは、「自分の環境で再現しているか」ではなく、「同じ文言が出ているか」です。今回の issue 群では、`socket connection was closed unexpectedly` の後に `verbose: true`
papoo.work
Claude Code で HTTP 500 が返るときにまず見るところ
Claude Code で HTTP 500 が返るときにまず見るところ
まず、この件は Claude Code 側から返ってくる `HTTP 500` です。Issue では、`Anthropic API Error: 500 Internal Server Error` という表現でまとまっていて、内容も `Internal server error` とだけ出ています。たとえば代表 issue の [#59832](https://github.com/anthropics/claude-code/issues/59832) には、API の 500 が出たことと、`status.claude.com` を確認するよう案内する文面が載っています。ほかの [#59778](https://github.com/anthropics/claude-code/issues/59778)、[#59748](https://github.com/anthropics/claude-code/issues/59748)、[#59753](https://github.com/anthropics/claude-code/issues/59753) も同じ症状です。
papoo.work
`[Tool result missing due to internal error]` が出て AskUserQuestion が返らないときに確認したこと
`[Tool result missing due to internal error]` が出て AskUserQuestion が返らないときに確認したこと
この症状に当てはまるのは、`AskUserQuestion` の呼び出しで質問ウィジェットが最後まで出ず、途中で `Tool execution was interrupted` になり、モデル側には `[Tool result missing due to internal error]` が返るケースです。 報告されている issue は [#74797](https://github.com/anthropics/claude-code/issues/74797) です。もう一つ、長時間セッションでセッションプロセスが勝手に再起動し、バックグラウンドタスクの orphan 化や tool result の欠落が起きるという [#85181](https://github.com/anthropics/claude-code/issues/85181) もあります。 ただし、今回の手元確認だけでは、両者が同じ原因だとは断定できません。現時点では別件の可能性もあります。 まず、手元の環境では Claude Code は次の状態でした。 ```text $ claude --versi
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出るときに確認したこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出るときに確認したこと
この症状は、少なくとも今回の issue では Windows 上で報告されています。該当する報告は [#79401](https://github.com/anthropics/claude-code/issues/79401) と [#85333](https://github.com/anthropics/claude-code/issues/85333) の 2 件で、どちらも同じエラー文字列を含んでいます。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=168 messages=167 range=[104,168)) ``` ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=85 messages=84 range=[68,85)) ``` まず切り分けとして、このエラーが「表示中のメッセージ一覧の整合性が崩れた」タイプのものかど
papoo.work
`VM connection timeout after 60 seconds` が出るときに、まず見るところ
`VM connection timeout after 60 seconds` が出るときに、まず見るところ
この症状は、少なくとも今回渡された issue では 2 つの見え方に分かれています。ひとつは Windows 11 ARM64 / Snapdragon X 系で、VM の起動や共有設定までは進むのに、ゲストがホストへ戻ってこず 60 秒で失敗するパターンです。もうひとつは、VM の状態が残ったままになり `smol-bin.vhdx` が掴まれ続けるパターンです。前者は [#85739](https://github.com/anthropics/claude-code/issues/85739)、後者は [#79270](https://github.com/anthropics/claude-code/issues/79270) に書かれています。 ただし、今回の二件だけでは「同じ原因」とまでは言えません。[#85739](https://github.com/anthropics/claude-code/issues/85739) では、VM 自体は始まっていて、`add_plan9_shares` までは 500ms 未満で終わる一方、その先のゲスト接続待ちで止まっています
papoo.work
`exit code 3` が出るときにまず見る場所
`exit code 3` が出るときにまず見る場所
`Claude Code process exited with code 3` が出ても、すべてが同じ原因とは限りません。少なくとも今回集めた issue では、Windows 側で常駐している Windhawk が関わるケースと、Hyper-V の仮想マシン内で Claude Code のバイナリが落ちるケースが別々に報告されています。 自分の症状がどちらに近いか、先に分けるのがよさそうです。 ターミナルでは動くのにデスクトップアプリ側だけで落ちるなら、[#52386](https://github.com/anthropics/claude-code/issues/52386) の報告とかなり似ています。報告者は「昨日までは動いていたが、今日は毎回 `Claude Code process exited with code 3` になる」「terminal では引き続き動く」と書いています。さらに Windhawk を終了すると直るとも述べています。 一方で、Windows の Cowork 経由で、VM の起動自体は成功するのに Claude Code の binary が始ま
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error":"Rate limited"} で止まるときに、まず確認したいこと
Error: 429 {"type":"error","error":{"type":"rate_limit_error":"Rate limited"} で止まるときに、まず確認したいこと
同じ形のエラーが出ているなら、少なくとも今回の issue 群では Claude Code 側から「サーバーが一時的にリクエストを制限している」と案内されていました。報告されている文言は、どちらも `API Error: Server is temporarily limiting requests (not your usage limit)` か、あるいは `Rate limited` です。対象になっている issue は [#73509](https://github.com/anthropics/claude-code/issues/73509) と [#73151](https://github.com/anthropics/claude-code/issues/73151) です。 この症状が自分のケースかどうかを見るなら、まずエラー本文が一致するかを見ます。今回の報告では、少なくとも次の形が共通していました。 ```text Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} のときに、まず切り分けたいこと
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} のときに、まず切り分けたいこと
この症状は、Claude Code が API から `429` と `rate_limit_error` を受け取って止まるものです。今回集まっている issue は 3 件とも解決済みで、どれも同じ系統のエラー文字列を含んでいました。 報告内容で共通しているのは、単なる「使いすぎ」で出る制限ではなく、`API Error: Server is temporarily limiting requests (not your usage limit)` と読める点です。つまり、少なくとも issue 上では「自分の利用上限に達した」とは書かれていません。サーバー側の一時的な制限として扱われています。 実際の報告では、次の文字列がそのまま出ています。 ```text Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"},"request_id":"req_011CdBp6diwVhNmSZmaw4Xjm"} at generate (B:/~BUN/root/src/
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} に出たときにまず見ること
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} に出たときにまず見ること
この症状は、Claude Code の実行中に `Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"}}` が返ってくるものです。今回集められた 3 件の issue はすべて closed で、しかも代表 issue へのコメントでは「サーバー側の一時的な制限」であり「your usage limit ではない」と案内されています。少なくとも issue の本文だけを見る限り、利用者の契約上限を超えた話としては扱われていません。 自分のケースかどうかを見分ける手がかりは、エラーメッセージの中身です。今回の症状クラスタでは、どの報告でも同じ形の 429 が出ています。 ```text Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"},"request_id":"req_011Cd634q9TpgJDhp2BnFWFZ"} at generat
papoo.work
this version can't be shared publicly が出るときに見たことと、まだ分からないこと
this version can't be shared publicly が出るときに見たことと、まだ分からないこと
この症状は、Claude Code で Artifact を公開共有しようとしたとき、共有ダイアログに > This version can't be shared publicly. Publish a new version or change the shared version, then try again. と出るケースです。手元で確認した issue でも、同じ文言がそのまま報告されています。たとえば [#80321](https://github.com/anthropics/claude-code/issues/80321) は「再公開しても共有できない」、[#80545](https://github.com/anthropics/claude-code/issues/80545) は mermaid ブロックを含む Artifact で同じエラーが出る、[#85550](https://github.com/anthropics/claude-code/issues/85550) は Max plan の Linux 環境で共有不可が続く、という内容でした。 まず
papoo.work
`exit code 132` が出るときにまず疑うこと
`exit code 132` が出るときにまず疑うこと
`exit code 132` が出ている場合、少なくとも今回の issue では「起動した Claude Code のプロセスが SIGILL で落ちる」系の話として報告されています。 該当する報告は [#73504](https://github.com/anthropics/claude-code/issues/73504) と [#85571](https://github.com/anthropics/claude-code/issues/85571) です。 ただし、同じ `132` でも原因は一つではなさそうです。#73504 は「最初のクエリ以降ずっと `Claude Code process exited with code 132`」という報告で、#85571 は「SSE4.2 / POPCNT を満たさない CPU で `Illegal instruction (core dumped)` が出る」という報告でした。後者は AVX だけの問題ではない、と明記されています。 まず、自分のケースがどちらに近いかを見分けるのが先です。 `Illegal instruct
papoo.work
ENOTFOUND が出るときに、まず切り分けたいこと
ENOTFOUND が出るときに、まず切り分けたいこと
`ENOTFOUND` は、少なくとも今回の issue 群では「DNS が引けていない」系の失敗として現れています。ただし、同じ見え方でも原因は 1 つではありません。今回確認できた範囲では、`claude update` で失敗するケースと、macOS のスリープ復帰後に OAuth の更新がこけるケースが並んでいます。 症状の入口としては、`claude update` や Web 系の操作で `ENOTFOUND` / `ETIMEDOUT` が出て、その後にログイン状態が崩れるか、アップデートだけ失敗するかを見ます。参照できる issue は [#71699](https://github.com/anthropics/claude-code/issues/71699) と [#85149](https://github.com/anthropics/claude-code/issues/85149) です。 まず、自分の環境で Claude Code がどう入っているかは確認しておいたほうがよさそうです。手元の出力では、`claude doctor` が複数インストールを検
papoo.work
Error: 403 {"type":"error","error":{"type":"permission_error`: Claude Code で「OAuth authentication is currently not allowed for this organization.」が出るとき
Error: 403 {"type":"error","error":{"type":"permission_error`: Claude Code で「OAuth authentication is currently not allowed for this organization.」が出るとき
このエラーが出るのは、Claude Code が OAuth 認証で進もうとして、所属組織側でそれが許可されていないときです。少なくとも issue の報告では、`Your organization has disabled Claude subscription access for Claude Code` という案内とあわせて `OAuth authentication is currently not allowed for this organization.` が返っています。該当する報告は [#63685](https://github.com/anthropics/claude-code/issues/63685) と [#63886](https://github.com/anthropics/claude-code/issues/63886) です。 まず見分けたいのは、自分が「個人の Pro 契約を持っているのに弾かれている」のか、それとも本当に組織管理下のアカウントとして扱われているのか、です。[#63886](https://github.com/anthro
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Your credit balance is too low to access the Anthropic API."}} が出るときに確認したこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Your credit balance is too low to access the Anthropic API."}} が出るときに確認したこと
このエラーが出た 2 件の issue は、どちらも本文にあるメッセージが同じでした。[#85675](https://github.com/anthropics/claude-code/issues/85675) も [#66297](https://github.com/anthropics/claude-code/issues/66297) も、報告されているのは `Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits."}}` です。 まず切り分けたいのは、Claude Code 自体の壊れ方ではなく、API 側の残高不足として返ってきているのかどうかです。少なくとも issue の記載上は、その方向を示しています。`invalid_requ
papoo.work
ECONNREFUSED が出るときにまず見るところ
ECONNREFUSED が出るときにまず見るところ
Claude Code で `ECONNREFUSED` にぶつかったとき、いま手元で確認できる範囲では、少なくとも「ローカルサービスに向けた接続」と「Windows 11 での接続失敗」という 2 つの報告がありました。どちらも、単純な通信エラーに見えて、実際には接続先の見え方や実行環境が絡んでいそうです。 自分のケースかどうかを見分ける起点は、ローカルホスト宛てかどうかです。`localhost` や `127.0.0.1` に向けた通信で落ちるなら、[ #65482](https://github.com/anthropics/claude-code/issues/65482) の報告にかなり近いです。そこでは、Linux の bwrap サンドボックス環境で `sandbox.network.allowedDomains` に `localhost` と `127.0.0.1` を入れても、期待通りにローカルサービスへつながらないとされています。理由として、実行時に `NO_PROXY=localhost,127.0.0.1,...` が設定され、HTTP クライアントがサンド
papoo.work
Claude Code で `EPIPE` が出るときに見ておきたいこと
Claude Code で `EPIPE` が出るときに見ておきたいこと
まず、この症状が自分のケースかを切り分けます。今回の issue 群で共通しているのは、`claude` の実行中に通信まわりが壊れたとき、`EPIPE` を起点にセッションやプロセスの挙動が崩れる点です。 ひとつは、tool-use のターン中に `api.anthropic.com` への API 呼び出しが失敗したケースです。報告では、DNS 失敗、HTTP タイムアウト、接続リセットのような一時的なネットワーク障害が起きると、CLI が警告もなく静かに終了し、再試行もバックオフも見えなかったとされています。セッションは `/exit` を打ったように終わる、と書かれています。これは [#65474](https://github.com/anthropics/claude-code/issues/65474) の報告です。 もうひとつは、sandboxed command が `SIGKILL` で殺されたあとに SOCKS socket が残り、その後 main thread が dead socket に書き続けて `EPIPE` を繰り返すケースです。こちらは 100%
papoo.work
`Error: 429 {"type":"error","error":{"type":"rate_limit_error` が返るのに、使用量制限ではないと出るときに確認したこと
`Error: 429 {"type":"error","error":{"type":"rate_limit_error` が返るのに、使用量制限ではないと出るときに確認したこと
この症状は、Claude Code 側で API 呼び出しが 429 になり、エラーメッセージに `rate_limit_error` と `Rate limited` が出るものです。今回の issue 群では、いずれも同じ文字列が出ており、しかも「not your usage limit」「Server is temporarily limiting requests」と書かれています。つまり、少なくとも報告上は「自分の利用上限に達した」というより、サーバー側の一時的な制限として見えているケースです。参照できたのは [#73658](https://github.com/anthropics/claude-code/issues/73658)、[#73657](https://github.com/anthropics/claude-code/issues/73657)、[#73656](https://github.com/anthropics/claude-code/issues/73656)、[#73655](https://github.com/anthropics/cla
papoo.work
Claude Code で HTTP 401 が出るときに最初に見るところ
Claude Code で HTTP 401 が出るときに最初に見るところ
手元で確認できたのは、同じ `HTTP 401` でも中身が違う 2 つの系統です。ひとつは GitHub のリリース URL を取りにいく途中で `HEAD` が拒否されるケース、もうひとつは `headersHelper` で取った bearer が切れたあとに再取得へ戻らず、OAuth の動きに入ってしまうケースです。どちらも issue 報告としては別件ですが、見えている症状はかなり近いです。 まず、あなたのケースがどちら寄りかで分けると見やすくなります。GitHub-hosted の release archive を fetch していて、`http_head request` の時点で `401 Unauthorized` になるなら #70588 の線が濃いです。MCP サーバーで `headersHelper` を使っていて、トークンが期限切れになったタイミングで `401` が出るなら #82070 の症状に近いです。 `#70588` では、Claude Code cloud/web session で network egress を `"All domains
papoo.work
exit code 128 が出るときの Claude Code の見分け方と、いま分かっている範囲
exit code 128 が出るときの Claude Code の見分け方と、いま分かっている範囲
まず切り分けたいのは、同じ `exit code 128` でも起き方が別物だという点です。今回の材料には、少なくとも 2 つのパターンがあります。ひとつは Claude Code on the web の remote execution sandbox で `git clone` が github.com への HTTPS 通信を通せず、`pip install` の `git+https://...` 依存関係が落ちるケースです。もうひとつはデスクトップアプリで、リンクされた worktree で既にチェックアウト済みのブランチに対して `git switch` が主レポジトリ側で走り、Git が拒否して 128 で終わるケースです。前者は [#71230](https://github.com/anthropics/claude-code/issues/71230)、後者は [#85543](https://github.com/anthropics/claude-code/issues/85543) です。 まず、あなたの症状がどちら寄りかを見ます。 remote execu
papoo.work
`Error: Failed to submit feedback:401
`Error: Failed to submit feedback:401
at fo8 (/$bunfs/roo` が出るときに見えていたこと この文字列が出ているだけでは、原因をひとつに絞れません。今回見つかった issue は 2 件だけで、どちらも最終的には closed ですが、報告内容はかなり違っていました。まず自分のケースがどちらに近いかを切り分けるのが先です。 `[#64103](https://github.com/anthropics/claude-code/issues/64103)` では、Claude Code が bash コマンドを誤って生成し、並列実行のような動きでロックやエラーを起こし、しかも「成功した」と書き残した、という報告でした。報告されたエラーは `Error: Failed to submit feedback:403` です。 `[#65584](https://github.com/anthropics/claude-code/issues/65584)` は `/code-review ultra` 実行時のクラッシュで、`free credit` を消費したあと、結果を返す前に落ちています。こちらの基礎になっ
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le が出るときに、まず見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le が出るときに、まず見るところ
このエラーは、少なくとも今回集めた 5 件の issue では、Claude Code のメッセージ一覧の内部整合性が崩れたときに出ています。報告されている文面は共通していて、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で始まり、`keys=... messages=...` の件数が 1 ずれていました。たとえば `keys=132 messages=131`、`keys=177 messages=176`、`keys=199 messages=198`、`keys=92 messages=91`、`keys=613 messages=612` です。 今のところ、これは単発の操作ミスというより、入力やツール呼び出しの途中で UI 側のメッセージ列が壊れたように見えます。少なくとも issue の報告だけからは、利用者側で一律に再現できる手順までは見えていません。 自分のケースかどうかを切り分けるなら、まず「入力した内容そのもの」よりも「貼り付け・再送信・ツール呼び出しの直後に落ち
papoo.work
EACCESで止まるときにまず疑う3つのパターン
EACCESで止まるときにまず疑う3つのパターン
`EACCES` が出ても、原因はひとつではありません。今回の issue 群では、見た目は似ていても中身がかなり違いました。ひとつはファイルパスに Cyrillic の混入が起きて別の場所を作ろうとしてしまうケースで、[#41422](https://github.com/anthropics/claude-code/issues/41422) に報告があります。もうひとつは `~/.claude/settings.json` の保存まわりで、シンボリックリンクが 1 段ではなく 2 段つながっていると atomic write が失敗するケースで、[#78162](https://github.com/anthropics/claude-code/issues/78162) です。さらに Windows では、hook の実行先に App Execution Alias を指定すると `Executable not found in $PATH` と出る件が [#85475](https://github.com/anthropics/claude-code/issues/8547
papoo.work
`authentication_error` が出るとき、まず自分の症状かを切り分ける
`authentication_error` が出るとき、まず自分の症状かを切り分ける
Claude Code を使っていて `401` の `authentication_error` が急に出るなら、少なくとも今回集まっている報告では「認証が壊れた」というより、セッション中に OAuth token の期限切れや再認証が必要になっているケースが中心でした。 ただし、同じ `authentication_error` でも issue は 2 系統あります。 ひとつは、[#18225](https://github.com/anthropics/claude-code/issues/18225) のように、長く使っていたセッションで突然 401 が出始め、`/login` を何度も求められるパターンです。報告者は「months 使っていて、today から始まった」と書いています。エラーメッセージは次のとおりです。 ```text API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth token has expired. Please
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず自分の再現条件を疑う
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず自分の再現条件を疑う
この症状は、Issue に出ている文字列がかなり特徴的です。手元で確認できた範囲では、少なくとも [#85341](https://github.com/anthropics/claude-code/issues/85341) と [#85332](https://github.com/anthropics/claude-code/issues/85332) の両方で、同じ ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=52 messages=51 range=[7,52)) ``` または近い形のエラーが報告されています。どちらも open で、解決済みの報告ではありません。したがって、少なくとも現時点では「特定のユーザー設定だけが原因」とは言い切れません。 実際に出ている差分は、`itemKeys` と `messages` の数が一致していないことです。Issue のログでは `keys=52 messages=51`、もう一方では `keys=180 m
papoo.work
`Persistent RPC: connection ended: failed to read length: EOF` が出るとき、まず疑うべきこと
`Persistent RPC: connection ended: failed to read length: EOF` が出るとき、まず疑うべきこと
この症状は、手元の issue 報告を見る限り、少なくとも Windows で Claude Desktop / Claude Browser MCP を使った直後に再現しています。#85199 では Claude Desktop が何度もクラッシュし、Windows 側に「Advanced Options → Repair」を促す表示が出ています。#85305 では Claude Browser MCP の `preview_start` が成功した直後に、セッションがそこで途切れています。どちらも、画面上のエラーより前に、RPC や MCP のやり取りが途中で切れているように見えます。 参照した issue は [#85199](https://github.com/anthropics/claude-code/issues/85199) と [#85305](https://github.com/anthropics/claude-code/issues/85305) です。 自分のケースかどうかを切り分けるなら、まず「ブラウザ系の MCP 操作の直後に落ちるか」「Claude
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出るときに見えたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出るときに見えたこと
このエラーは、こちらで確認できた範囲では 3 件の issue に共通していました。どれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で始まり、`itemKeys` と `messages` の件数がずれていることを示しています。読者が自分のケースかどうかを見るなら、まずこの文字列が出ているかを確認するのが早いです。 報告は [#85344](https://github.com/anthropics/claude-code/issues/85344)、[#85196](https://github.com/anthropics/claude-code/issues/85196)、[#85112](https://github.com/anthropics/claude-code/issues/85112) の 3 件でした。いずれも open で、解決済みではありませんでした。 手元で取得できた CLI の状態は次の通りです。 ```text $ claude --version
papoo.work
`Error: 429 {"type":"error","error":{"type":"rate_limit_error"` が出て、Claude Code が「You've hit your limit」と返すとき
`Error: 429 {"type":"error","error":{"type":"rate_limit_error"` が出て、Claude Code が「You've hit your limit」と返すとき
この症状は、Issue の報告ではどちらも 429 の rate limit エラー として出ています。メッセージは同じで、どちらも `This request would exceed your account's rate limit. Please try again later.` という文言を含んでいました。該当する報告は [#56991](https://github.com/anthropics/claude-code/issues/56991) と [#64462](https://github.com/anthropics/claude-code/issues/64462) です。 まず切り分けたいのは、「自分のアカウント上限に本当に達しているのか」と「別の不具合で 429 に見えているだけなのか」です。今回の issue 群だけを見ると、どちらも利用枠が尽きたように見える一方で、報告者は「小さなプロジェクトなのに短時間で尽きた」「1 つのバグ対応で日次トークンを使い切った」と述べています。つまり、少なくとも体感としては“通常の使い方ではない消費”に見えていた
papoo.work
EEXIST: Claude Code の Bash ツールが `mkdir` で落ちるときに見えたもの
EEXIST: Claude Code の Bash ツールが `mkdir` で落ちるときに見えたもの
まず、自分のケースかどうかを切り分けます。今回の報告で共通していたのは、Windows 上で Claude Code を使っていること、そして `EEXIST` が出ていることでした。ひとつは worktree の扱いで「git リポジトリではない」と誤判定される話、もうひとつは `~/.claude/session-env/<session-id>` を作るところで `mkdir` が `EEXIST` になる話です。前者は [#40164](https://github.com/anthropics/claude-code/issues/40164)、後者は [#65309](https://github.com/anthropics/claude-code/issues/65309) です。 ただし、筆者の手元で確認できたのは macOS 上の Claude Code 2.1.207 までです。Windows で同じ再現確認はしていません。なので、ここで書けるのは「こういう症状の issue が実際にある」「手元の環境ではこのバージョンとこの導入状態だった」という範囲に限られます
papoo.work
EPERM が出るのは、SMB 上のファイル操作が怪しいときだった
EPERM が出るのは、SMB 上のファイル操作が怪しいときだった
まず自分のケースかどうかを見るなら、今回集めた issue では「ネットワーク越しのボリューム」や「Windows のパス解決」で `EPERM` が出ています。ローカルディスクの単純な読み書きではなく、保存先や対象が少し特殊なときに崩れていました。 たとえば macOS では、SMB マウントされた volume 上のファイルに対して Read/Bash を走らせると `Operation not permitted` が返る報告があります。報告者は mount の所有者で、`smbutil statshares` でも SMB 3.1.1 と暗号化有効を確認していました。それでも `dangerouslyDisableSandbox: true` では止められず、`--add-dir /Volumes/storage` か `permissions.additionalDirectories` を追加する回避策しか見つかっていませんでした。これが [#57540](https://github.com/anthropics/claude-code/issues/57540) です。
papoo.work
ENOSPC が出ても本当にディスクが空なのか、まずここを見たい
ENOSPC が出ても本当にディスクが空なのか、まずここを見たい
この症状は、Claude Code が `ENOSPC` とともに「temp filesystem is full (0MB free)」「Command output was lost...」のような文言を出すのに、実際には空き容量があるケースとして報告されています。少なくとも issue 上では、ディスク不足そのものではない例が 2 件ありました。ひとつは [#65086](https://github.com/anthropics/claude-code/issues/65086) で、`stdout` も `stderr` も出さずに非 0 終了した subprocess に対して、偽の `ENOSPC` が出たという報告です。もうひとつは [#65251](https://github.com/anthropics/claude-code/issues/65251) で、macOS 上で Bash tool の出力取得が失敗し、`/private/tmp/claude-501/.../tasks` の temp filesystem が満杯だと誤判定されたという報告でした。
papoo.work
Claude Code で HTTP 403 が出るときに見るべきところ
Claude Code で HTTP 403 が出るときに見るべきところ
まず、この `HTTP 403` がどこから返ってきているかで話が変わります。今回の症状クラスタに入っている issue は、どちらも「対象サイト側の拒否」ではなく、Claude Code 側の egress proxy が弾いているように見える報告でした。`[#34690](https://github.com/anthropics/claude-code/issues/34690)` では `x-deny-reason: host_not_allowed` が見え、`[#85330](https://github.com/anthropics/claude-code/issues/85330)` では auto mode classifier によるブロックが繰り返し起きています。 筆者の環境で `claude doctor` を見ると、少なくともインストール状態そのものは致命的には壊れていませんでした。ただし、`Multiple installations found` と `Leftover npm global installation` の警告は出ています。これは今回の `
papoo.work
Permission denied が出るときにまず見るところ
Permission denied が出るときにまず見るところ
Claude Code で `Permission denied` が出る話は、今回の issue 群だと 2 つの顔があります。ひとつは SSH 越しのセッションが再起動後におかしくなるケース、もうひとつは MCP 経由でページ操作が拒否されるケースです。どちらも同じ文言に見えますが、症状の出方はかなり違います。 SSH 側は [#72335](https://github.com/anthropics/claude-code/issues/72335) です。報告では、デスクトップアプリで SSH セッションを使っていると、再起動後に過去のセッション履歴が空白になったり、SSH セッションの fork/branch が失敗したりします。報告されている根本原因は、過去セッションを開くときにデスクトップアプリが 2 つの SSH 処理を走らせ、そのうち byte-sync は SSH config のエイリアスを使う一方、tail 側が raw IP に接続してしまう、というものです。こちらは issue 本文が途中で切れているため、tail 側の接続先の詳細は分かりません。少なくとも
papoo.work
Claude Code で background task や Monitor が突然落ちて exit code 144 になるとき
Claude Code で background task や Monitor が突然落ちて exit code 144 になるとき
まず切り分けたいのは、あなたの症状が「長く動かしているバックグラウンド処理が、本人の操作なしに止まる」タイプかどうかです。今回の issue 群では、どちらも Claude Code のバックグラウンド実行に絡んで exit code 144 が出ています。 手元で確認できた Claude Code CLI の情報はこれです。 ```text $ claude --version 2.1.207 (Claude Code) ``` 背景エージェント関連のコマンドは存在しています。 ```text $ claude agents --help Usage: claude agents [options] Manage background agents Options: --add-dir <directory> Additional directory to allow tool access in dispatched sessions (repeatable) --agent <agent> Default
papoo.work
`invalid_request_error` が返るときに見ておきたいこと
`invalid_request_error` が返るときに見ておきたいこと
まず、自分のケースかどうかを切り分けます。今回の issue 群では、同じ `invalid_request_error` でも中身がかなり違いました。 一方の [#64796](https://github.com/anthropics/claude-code/issues/64796) は、`/schedule` が `POST /v1/code/triggers` を使って新しい trigger を作れない、という報告です。こちらは `events[0] event_type is required` と出るのに、別の経路では `event_type` が `unknown field event_type` として拒否される、つまり v1 と v2 の変換が噛み合っていない状態だと書かれていました。既存の trigger は動き続けるが、作成や一部更新が失敗する、というのが報告内容です。 この2件に共通しているのは、エラー名は同じでも「画像処理系の失敗」と「トリガー作成のスキーマ不整合」で、症状の入口が違うことです。なので、`invalid_request_error` だけを
papoo.work
529 Overloaded が出るだけでなく、途中で止まるケースもある
529 Overloaded が出るだけでなく、途中で止まるケースもある
まず切り分けたいのは、あなたが見ている `529` が「単発のサーバー側エラー」なのか、それとも長時間・並列実行の途中で繰り返し出るタイプなのかです。今回の issue 群では、その両方が報告されています。 手元で確認できた CLI の状態は次の通りです。 ```text $ claude --version 2.1.207 (Claude Code) ``` ```text $ claude doctor Claude Code doctor Running: native (2.1.207) Commit: bc512d563325 Platform: darwin-arm64 Path: ~/.local/share/claude/versions/2.1.207 Config install method: native Search: OK (bundled) Auto-updates: enabled Auto-update channel: latest Last update attempt: none recorded Multiple installations f
papoo.work
ECONNRESET が出るときに、まず疑うべきこと
ECONNRESET が出るときに、まず疑うべきこと
Claude Code で `ECONNRESET` が出る症状は、issue を見る限り 1 つの形にまとまっていません。少なくとも、同じマシンで Chat は普通に動くのに Code 系の画面だけ失敗する例がありますし、Windows では API ストリームの途中で切れる例、再試行を重ねても失敗が続く例もあります。参照できた報告は [#70599](https://github.com/anthropics/claude-code/issues/70599)、[#83994](https://github.com/anthropics/claude-code/issues/83994)、[#84818](https://github.com/anthropics/claude-code/issues/84818)、[#84072](https://github.com/anthropics/claude-code/issues/84072) です。 まず、自分のケースがどれに近いかを見ます。 Chat mode だけは通るのに、Cowork Scheduled tasks や C
papoo.work
ENOENT が出たら、まず見るところは「どの呼び出しで落ちているか」
ENOENT が出たら、まず見るところは「どの呼び出しで落ちているか」
同じ `ENOENT` でも、今回の issue 群では原因がかなり分かれています。 手元の環境では `claude doctor` が正常に通っていて、`claude` の実体も複数見つかっています。なので、少なくとも「インストール全体が壊れている」とは言い切れません。 ```text $ claude doctor Claude Code doctor Running: native (2.1.207) Commit: bc512d563325 Platform: darwin-arm64 Path: ~/.local/share/claude/versions/2.1.207 Config install method: native Search: OK (bundled) Auto-updates: enabled Auto-update channel: latest Last update attempt: none recorded Multiple installations found npm-global at /usr/local/bin/claude nati
papoo.work