Author

claudehowto

ERR_CONNECTION_CLOSED が出たときに、まず見分けたいこと

ERR_CONNECTION_CLOSED という文字列だけを見ると、ひとつの原因に見えてしまいます。ですが、今回の issue 群を見る限り、少なくとも二つの出方があります。

ひとつは、Cowork の macOS Desktop でチャット用の webview がネットワークを失って、そのまま戻らなくなるケースです。報告では、エージェント側の処理は続いているのに、画面側だけが壊れたままになり、送ったメッセージが灰色の「ghost bubble」として残るとされています。AskUserQuestion も描画されず、自動で拒否されたように見える、と書かれています。これは #65382 の報告です。

もうひとつは、Windows の auto-updater で、Electron のネットワーク層だけが ERR_CONNECTION_CLOSED を返すケースです。報告では、curl と node https.get() では同じ更新先に届くのに、Electron では失敗し、さらに失敗時にバックオフなしで即再試行を繰り返す、とされています。これは #71524 です。

自分のケースを切り分けるなら、まず症状の出方を見ます。チャット画面だけが壊れていて、裏側のセッションは生きていそうなら #65382 に近いです。更新確認の場面で、同じ接続失敗が延々と続くなら #71524 に近いです。少なくとも、今回の報告だけでは「ERR_CONNECTION_CLOSED なら必ずこの原因」とは言えません。

Issue の追記には、原因の見立てが少し絞られています。2026-06-04 15:34 の件だけは、renderer の Failed to fetch の連続と main-process の net::ERR_CONNECTION_CLOSED が挟み込む形で確認できた一方、ほかの失敗ではネットワークエラーの記録が見つからなかった、とあります。つまり、見た目は同じでも、全部が同じ原因とは限らない、ということです。

現時点で裏が取れているのはここまでです。回避策として一般化できる手順は、この資料だけでは書けません。少なくとも issue からは、Cowork の webview 側が落ちたまま戻らない場合はアプリ再起動でしか抜けられなかったこと、Windows の更新問題では Electron 側だけ失敗していたことが読み取れますが、恒久策は未確定です。

検証環境の実測出力は次のとおりです。

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

今回の資料から言えるのは、ERR_CONNECTION_CLOSED は「接続が閉じた」という結果名にすぎず、Claude Code では少なくとも webview の不調と auto-updater の不調の両方で現れている、という点です。症状の出る場面を先に見たほうが早いです。

検証環境

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

参照した Issue（anthropics/claude-code）: #65382, #71524

同じ著者の記事

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

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

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

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

`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

`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

`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

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

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