Author

claudehowto

Error: 400 {"type":"error","error":{"type":"invalid_request_error":"messages.3: role 'system' must precede an 'assistant' message or end the array; まず確認したいのは compaction 後に会話を再開しようとしていないかです

同じ系統の報告が 2 件ありました。#73821 は messages.67 に対して role 'system' must precede an 'assistant' message or end the array と出ており、#88276 は Unable to start conversation after compaction のあとに、同種の 400 エラーが返っています。少なくとも issue 上では、どちらも「messages 配列の中で system の位置が不正」と読める内容でした。

手元で確認できた一次情報では、実行環境は次のとおりです。

[env_summary]
OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-09-28T08:53:08+09:00

この症状が出るケースは、少なくとも報告から見る限り、通常の会話中というより compaction のあとに会話を再開しようとした場面が怪しいです。#88276 のタイトルがまさにそれでした。一方で、#73821 では messages.67 の位置で system の並び順が問題だと返されています。どちらも Claude Code 側が API に送るメッセージ列の組み立てで、system メッセージの位置が崩れたときに出るエラーに見えますが、ここは issue の文面からそう読める、という範囲です。内部実装までは分かりません。

いま確認できる範囲で、読者側が切り分けるなら次の見方になります。compaction を挟んだ直後に会話を続けようとしたときだけ出るのか、それとも長い会話の途中で再現するのか。後者まで広がるなら、#73821 のようにメッセージ番号付きで落ちる可能性があります。前者に限られるなら、#88276 とかなり近い症状です。

ただし、今回渡された情報だけでは、恒久的な回避策や修正済みかどうかは断定できません。代表 issue のコメントも「Closing for now — inactive for too long. Please open a new issue if this is still relevant.」というもので、解決方法そのものは示されていませんでした。なので、現時点では「原因は system メッセージの配置不整合らしい」「compaction 後の再開で起きやすそう」というところまでが、資料から言える上限です。

再現したときは、少なくともエラー本文に出る messages.<番号> と request_id は控えておく価値があります。#73821 には request_id が含まれていましたし、#88276 でも Request ID for the report が付いていました。報告時にそのまま貼れる材料になります。

検証環境

OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-09-28T08:53:08+09:00

参照した Issue（anthropics/claude-code）: #88276, #73821

同じ著者の記事

`Error

at generate (/$bunfs/root/src/entrypoints/cli.js:1` が出て作業が止まるときに見ること この症状は、Claude Code の処理中に `generate` から `makeRequest` へ進む途中で落ちているケースです。報告されている issue はどちらも macOS 上で発生していて、[#70256](https://github.com/anthropics/claude-code/issues/70256) では `403 The socket connection was closed unexpectedly` を伴う例がありました。[#69826](https://github.com/anthropics/claude-code/issues/69826) では同じ系統のスタックトレースが、エラー詳細なしで繰り返し出ています。 自分のケースかどうかは、まず表示される断片が次に近いかで見分けられます。 ```text Error at generate (/$bunfs/root/src/entrypoints/cl

papoo.work

`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

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

`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 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

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

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

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: 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

`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