Author

claudehowto

Session creation failed が出るときに見えているのは、たぶん「古い状態が残っている」こと

この症状に近いのは、Remote Control のセッション作成が失敗し、再接続や再登録をしてもすぐには直らないケースです。報告されている issue では、iOS の Claude app から Remote Control セッションを作ろうとすると Session creation failed — see debug log が出る一方で、ローカル側の claude-remote@* systemd サービスは healthy に見えていた、と書かれています。しかも、別のマシンから新しく Remote Control セッションを登録すると、影響を受けていた環境全体で復旧したそうです。これは #57715 にある報告です。

別の報告では、macOS で claude --remote-control ketobaza を開始したあとに Remote Control が切断され、Session creation failed が出たとされています。/remote-control で再接続しても反応がなく、/bug での報告も失敗し、最終的に server 500 になったという流れです。こちらは #87211 です。

まず、この 2 件に共通しているのは、「サービスやデーモンが完全に死んでいるようには見えないのに、新しいセッションだけが作れない」点です。少なくとも issue の文面からは、単純な起動失敗ではなく、以前のセッション情報が残っていて更新されていないように見えます。ただし、これは報告内容からの読み取りであって、原因を断定できる段階ではありません。

実際に手元で取得できている出力は環境情報だけです。問題の再現ログや追加のエラーメッセージは渡されていないので、ここではそれ以上は言えません。

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

この時点で言える切り分けは、少なくとも次のどちらかです。

• ローカルの Claude Code 側では接続先やセッション情報が残っているのに、Remote Control の側では新規セッションが通らない
• あるいは、報告にあるようにサーバー側にぶら下がる状態が古くなっていて、別マシンからの新規登録でしか回復しない

#57715 の報告では、別のマシンから再登録すると復旧したとあります。もし自分の環境で「ローカルのサービスは生きているのに Session creation failed だけが続く」なら、このパターンにかなり近いです。逆に、/bug まで 500 になる #87211 のほうは、単なるクライアント側の一時不調よりも、周辺の状態が壊れている可能性を感じさせます。とはいえ、どちらも issue ベースの話で、再現条件や恒久対策はまだ見えていません。

手元で確認するなら、まずは「今出ている Session creation failed が、Remote Control の再接続で出ているのか」「新規セッション作成のタイミングで出ているのか」を分けるのが先です。issue の内容だけを見る限り、既存セッションの復旧では足りず、新しい登録や別マシンからの再登録で状態が切り替わる例がある、というところまでは言えます。そこから先は、現時点では分かりません。

検証環境

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

参照した Issue（anthropics/claude-code）: #87211, #57715

同じ著者の記事

`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 で止まるときにまず見るところ

この症状は、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

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 の切り分けメモ

まず、手元の症状がこのクラスタに当てはまるかを見るなら、出方がかなり重要です。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を読めないときに見えること

まず、この症状に当てはまるかを切り分けます。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

Error: 400 {"type":"error","error":{"type":"invalid_request_error"} で止まる Claude Code の `/goal` と stop hook

まず切り分けたいのは、このエラーが「会話全体」ではなく、`goal` コマンドや stop hook の実行時に出ているかどうかです。今回の報告では、`/goal` が stop hook 側で失敗している例と、stop hook evaluator から `Prompt is too long` が返る例が並んでいます。`#61759` では「1M context window を無効にした状態で 200k tokens を超えると `/goal` が失敗する」と書かれており、通常の会話は 1M までは動くが、stop hook でだけ問題が出る、という切り分けになっています。`#62560` でも同じ系統で、stop hook evaluator の API エラーとして `Prompt is too long` が返っています。いずれも [#61759](https://github.com/anthropics/claude-code/issues/61759) と [#62560](https://github.com/anthropics/claude-code/issue

papoo.work

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.` が出るときに見るところ

このエラーは、少なくとも今回確認できた 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.) が出るときにまず見るところ

このエラーは、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` が出るときに、まず疑うこと

この症状は、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