Not ready after 60 secondsエラー — Claude DesktopのMCPタイムアウト対処

このTipsでできること

Claude DesktopでMCPが「Not ready after 60 seconds」と出るのは、アプリ内の起動プールが60秒以内にサーバーの準備完了を受け取れなかったときです。npx経由の起動が遅れる環境では、インストール済みの実行ファイルを直接指定すると解消した報告があります。

ただし、これは報告者の回避策で、公式の修正ではありません。切り分け方と、同じ設定がClaude Code CLIでは通る理由も扱います。

症状 — Claude Code CLIは繋がるのに、DesktopのMCPだけ失敗する

GitHub issue #92758は、Claude Desktop(Cowork build)、Windows 11 EnterpriseでローカルMCPサーバー5台が突然失敗した報告です。内訳はmcp-remote経由のリモート3台と、stdioのローカル2台でした。前日まで動いていた設定を変えていないのに、アプリの再起動直後から全サーバーがエラーになりました。

Desktop設定のローカルMCPサーバー一覧は、いずれも次の表示に変わります。「Couldn't start for Cowork and Code sessions. Error: Request timed out」です。ところが報告者がターミナルで次のコマンドを実行すると、同じ定義の全サーバーが接続済みと表示されました。

claude mcp list

この非対称な症状が不具合特定の手がかりです。issueにはbug・platform:windows・area:mcp・area:cowork・area:desktopのラベルが付き、オープンのまま残っています。

エラーが起きている場所 — DesktopのCodeタブとCoworkが共有する起動プール

Desktopアプリはclaude_desktop_config.jsonに定義したMCPサーバーを、Desktopのチャット画面だけでなくアプリ内の「Codeタブ」のローカルセッションにも読み込みます。同じサーバー名を~/.claude.jsonや.mcp.jsonにも定義している場合、Codeタブはclaude_desktop_config.json側の定義を優先します。

一方、単体のClaude Code CLI(ターミナルで動くclaudeコマンド)はclaude_desktop_config.jsonを読みません。CLIが読むのは~/.claude.jsonや.mcp.jsonなどのMCP設定です。Desktop側だけでエラーが出てCLIは接続できるという非対称は、この違いから生まれます。

Desktopの定義をCLIへ取り込むclaude mcp add-from-claude-desktopには、対応環境の制限があります。v2.1.289のヘルプの1行目は次のとおりです。

claude mcp add-from-claude-desktop --help

Import MCP servers from Claude Desktop (Mac and WSL only)

Windowsネイティブで動かすDesktopの定義は、この取り込みの対象外です。CLIへ載せたいときはclaude mcp addで書き直す形になります。

エラーのメタデータにはcontext: 'shared-pool'という値が現れます。issueの報告者は、これをDesktopのCowork画面とCodeタブが共有するMCPプロセスプールを指す内部ラベルだと見ています。ログを見る限り、このプールは各サーバーの起動を一括管理し、60秒以内に準備完了の合図を受け取れないと、実際の接続の成否に関係なく待機中のセッションへ失敗を返しているようです。claude_desktop_config.json自体の書き方はClaude Desktop MCP設定ガイドにまとめています。

ログが示す本当の順序 — タイムアウト宣言のあとに接続が成功している

%LOCALAPPDATA%\Claude\Logs\mcp-server-<name>.logを時刻順に並べると、接続の成功がタイムアウト宣言より後ろに来ます。次は、報告者がサーバーを1台に絞った構成で採取した1回分の流れです。

このログでは、失敗の実体は接続不能ではなく締め切り超過です。

報告された2つの構成

issueのコメント欄では、複数の環境からの報告を突き合わせて引き金が絞り込まれました。まずサーバー数を1台に減らしても同じエラーが34回、2〜10分おきに再発したため、複数サーバーが60秒の予算を奪い合うという説は否定されています。報告者は9月14日にmcp-remoteのOAuthやTLSを疑いましたが、9月16日に訂正しました。mcp-remoteのログにも、npmの証明書検証リトライが残っていたためです。

別の報告者は、npxもmcp-remoteも使わない自作の.mcpb拡張機能(node直起動のサーバー)で同じ「Connection closed」「Request timed out」に遭遇しています。同じ設定はClaude Code CLIからは問題なく動作し、Desktop側だけで失敗しました。

この環境のログにはEra probe verdict: legacy (sibling did not complete the exchange)という行が残っていました。報告者はVS Codeなど他のClaude Code画面をすべて閉じても、同じ失敗になることを確かめました。エラー文言の「Cowork and Code sessions」は、実在する2つ目の利用者を示すものではなく、汎用のラベルだという見立てです。別のコメントは、実在しない「sibling」の応答をプールが待っている可能性を指摘しました。

対処法 — npx経由の起動をやめてインストール済み実行ファイルを直接指定する

パターンAに該当した報告者は、claude_desktop_config.jsonのContext7サーバー起動コマンドを、npx経由からインストール済み実行ファイルの直接指定に変更しました。変更前は次のような設定でした。

{
  "command": "cmd",
  "args": ["/c", "npx", "-y", "@upstash/context7-mcp@3.2.2"]
}

これを、すでにインストール済みのバイナリを直接呼び出す形に変更します。パスは環境ごとに異なります。

{
  "command": "C:\\path\\to\\node_modules\\.bin\\context7-mcp.cmd",
  "args": []
}

報告者が記録した数字は次の3つです。

mcp-remote経由のConfluence・Jira・GitHubは、インストール済みのバージョン0.8.3のmcp-remoteを専用ディレクトリへコピーし、node.exeから直接呼ぶ構成に変えました。Playwrightも、インストール済みのエントリーポイントをNodeで直接起動しています。エンドポイント・認証値・環境変数は変更前のままです。

報告者は後日、元の説明を一部訂正しています。調べた端末では、CLIの設定がインストール済みのContext7実行ファイル、Desktopの設定がcmd /c npx -yと、起動経路が同じではありませんでした。issueを開いた当時の設定が一致していたかは、再確認されていません。「CLIでは通る」ことを根拠にするときは、両者が同じ起動経路かどうかを先に見ます。

npmのログには、レジストリのメタデータ取得でUNABLE_TO_VERIFY_LEAF_SIGNATUREが繰り返され、9回の試行のあと、約214秒でキャッシュ結果に落ちた記録がありました。npmのリトライ設定は8回です。報告者は、_npxの経路だけでは起動のたびにレジストリ照会が起きるとは言い切れず、根拠は取得とリトライのログだと書いています。社内プロキシ経由でこの待ちが起きると、60秒の枠を食います。インストール済みのパッケージへ直接パスを通せば、この待ちを通らずに済みます。

それでも直らないケースが残っている

npmの証明書検証で説明できたのは、報告者1人の環境だけです。もう一方の.mcpb拡張機能のケースはnpxもOAuthも経由しない構成で、同じ症状が再現しました。コメント主は、npx・プロキシ経由の遅延は引き金の一つに過ぎないと見ています。固定60秒のゲートそのものが共通の欠陥だ、という見立てです。報告者自身は、固定60秒が設計上の欠陥かどうかは今回の検証では確定しないとしており、.mcpbの事例は未解決です。

公式のWindows向けトラブルシューティングには、設定の確認・アプリの再起動・タスクマネージャーでのプロセス確認・サーバーログの確認が載っています。この共有プールの不具合そのものには触れていません。

企業ネットワーク環境では、プロキシやDLP(Data Loss Prevention)アプライアンスを原因と疑いたくなりますが、原因と決めつける前に確認が要ります。今回の報告環境でも、DLPアプライアンスが別のAPIエラーを断続的に出していました。ただしshared-poolのタイムアウトは8日間で約103回発生していたのに対し、DLPエラーは19回だけで、大半のタイムアウトはDLPエラーと時間的に重なっていませんでした。プロキシやDLPを止めて検証する前に、まず両方のログのタイムスタンプを突き合わせ、本当に連動しているかを確認する方が早く切り分けられます。

環境変数の引き継ぎ差も、コメントで疑われた線の一つです。報告者は9月14日時点で、こう見ていました。変数の欠落なら起動は一度きりで失敗するはずで、遅れて成功する今回の形とは合わない、という理由です。ただしこの見立ては、CLIとの設定の同一性を前提にしており、後の訂正で根拠が弱まっています。

この「60秒」とCLIのMCP_TIMEOUTは別物

Claude Code CLIにもMCPの60秒に関わる設定がありますが、仕組みが違います。MCP_TIMEOUT環境変数は本来、CLIがMCPサーバーの起動を待つタイムアウト(起動タイムアウト)を設定するもので、たとえばMCP_TIMEOUT=10000 claudeのように指定します。HTTP・SSE・claude.aiコネクタのMCPサーバーに限っては、このMCP_TIMEOUTが二次的な用途にも使われます。

最初のレスポンスバイトが届くまでのリクエスト単位のタイマーを、「60秒・そのサーバーに適用されるツールのタイムアウト・MCP_TIMEOUTのうち最大値」で決める仕様です。MCP_TIMEOUTを60秒より小さくしても、タイマーは短くなりません。

これは、ツール呼び出しを含む各リクエストが最初のレスポンスバイトを得るまでの制限です。stdio・WebSocketのサーバーには、このリクエスト単位のタイマー自体がありません。今回のDesktopの「Not ready after 60 seconds」は接続の準備段階の話で、Desktopアプリ内部の起動プールが持つ別の期限です。issueのスレッドには、MCP_TIMEOUTを伸ばして共有プールの60秒を延ばせたという報告はありません。

MCPサーバーの一般的な設定・スコープ・タイムアウト調整はClaude Code MCP設定ガイドにまとめています。claude mcp add-from-claude-desktopで一部のサーバーだけ取り込みに失敗する別のエラーはCould not import a serverエラーを参照してください。stdioサーバーへの環境変数の扱いはCLAUDE_CODE_MCP_ALLOWLIST_ENVとはも参考になります。実際のstdioサーバーの例はBlender MCPの導入手順にあります。