Author

claudehowto

Starting connection with timeout of 30000ms が出るときに、まず疑うこと

この文字列が出たからといって、ただちに「通信が遅い」の一言では片づきません。今回の 2 件の issue では、どちらも MCP サーバーが期待どおり起動しない、あるいは起動のしかたが想定とずれる ところまで話が進んでいました。

• #93134 は、Windows 上で desktop-commander プラグインが起動時に落ち、npm が Invalid Version: と空の version value を返しているケースです。報告では、サーバープロセスが始まる前に失敗し、クライアント側は CONNECTION_CLOSED を受け取っています。
• #85895 は、プロジェクトの .mcp.json にある stdio サーバーが 1 回の起動で 2 回立ち上がる現象です。報告者の環境では、バックエンドが 1 接続しか受けないため、2 回目の接続が拒否されて Failed to fetch tools: Not connected になっています。

つまり、この症状は「接続先が遠い」よりも、「起動時にサーバーが落ちる」「同じサーバーが二重に起動する」といった、MCP 側の立ち上がり方に目を向けたほうがよさそうです。

自分のケースかどうかを見る

まず見たいのは、エラーの出方です。Starting connection with timeout of 30000ms のあとに、CONNECTION_CLOSED や Invalid Version: が続くなら、#93134 の流れにかなり近いです。少なくともその issue では、プラグインの manifest 経由で起動した desktop-commander の MCP サーバーが、npm の時点で止まっていました。

一方で、ツールがまったく見えない、あるいは「接続されていない」といった状態なら、#85895 のような二重起動も疑えます。こちらは、1 回目の起動が client-manager のログに載らないまま先に走り、少し遅れて 2 回目が正規の経路で起動する、という報告でした。

事実として確認できること

筆者の環境では、検証時点の基本情報だけ確認できています。

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

この出力だけでは、今回の症状が再現したとは言えません。少なくとも、issue 報告にある Windows 固有の desktop-commander 問題や、mcp-remote を含む二重起動問題を、この環境で裏取りできたわけではありません。

いまのところ言える範囲

現時点で確実なのは、Starting connection with timeout of 30000ms が出る背景に、少なくとも次の 2 パターンがあることです。

1つは、起動途中で MCP サーバー自体が落ちるケースです。#93134 では Invalid Version: が出ており、接続確立以前の失敗でした。

もう1つは、同じ stdio サーバーが同じプロセスから複数回起動されるケースです。#85895 では、二重起動そのものが問題を起こし、結果として tools の取得に失敗しています。

どちらにせよ、まずは「MCP サーバーが 1 回だけ、最後まで立ち上がっているか」を見るのが先です。timeout の文言だけを見てネットワークの遅延を疑うと、見当違いになりやすいです。

検証環境

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

参照した Issue（anthropics/claude-code）: #93134, #85895

同じ著者の記事

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

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) が出るとき、まず確認したいこと

この症状に当てはまるかどうかは、かなりはっきりしています。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 の再送で通る症状

自分のケースかどうかを先に切り分けるなら、確認したいのは「ツール呼び出しが最初の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 を見たときに確認したいこと

この症状でまず目に入るのは、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)` が出るときに、まず疑うこと

このエラーは、少なくとも報告上は 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` が「自分の環境でも再現する、同じ系統の問題かどうか」です。今回の 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` で止まるときに見ておくこと

まず、自分のケースかどうかを絞ります。今回の症状クラスタでは、どちらの 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.

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

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