Not ready after 60 secondsエラー — Claude DesktopのMCP起動失敗
ローカルMCPサーバーが「Not ready after 60 seconds」で失敗しても、Claude Code CLIだけは接続に成功する理由と、GitHub issueで確認された対処法をまとめます。
このTipsでできること
Claude DesktopでローカルMCPサーバーが「Not ready after 60 seconds」エラーになったときの切り分け方と、GitHub issueで確認済みの対処法をまとめます。同じ設定が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だけです。これが、Desktop側だけでエラーが出てCLIは無関係に接続できる理由です。
エラーのメタデータにはcontext: 'shared-pool'という値が現れます。issueの報告者は、これをDesktopのCowork画面とCodeタブが共有するMCPプロセスプールを指す内部ラベルだと見ています。ログを見る限り、このプールは各サーバーの起動を一括管理し、60秒以内に準備完了の合図を受け取れないと、実際の接続の成否に関係なく待機中のセッションへ失敗を返しているようです。claude_desktop_config.json自体の書き方はClaude Desktop MCP設定ガイドにまとめています。
ログが示す本当の順序 — タイムアウト宣言のあとに接続が成功している
%LOCALAPPDATA%\Claude\Logs\mcp-server-<name>.logを突き合わせると、意外な順序が見えます。プール側が「Not ready after 60 seconds; the sessions waiting for it started without it」と「Request timed out」を報告したあとに、mcp-remoteのログで実際のリモート接続(Proxy established successfully)やinitializeメッセージが記録されていました。
つまり接続自体は失敗していません。プールが定めた60秒の締め切りに間に合わなかっただけで、締め切りを過ぎた直後に本来の接続は完了しています。ただしプール側はすでに待機セッションへ失敗を通知したあとなので、遅れて届いた接続はnotifications/cancelledで打ち切られ、破棄されます。
確認されている2つの引き金
issueのコメント欄では、複数の環境からの報告を突き合わせて引き金が絞り込まれました。まずサーバー数を1台に減らしても同じエラーが34回、2〜10分おきに再発したため、複数サーバーが60秒の予算を奪い合うという説は否定されています。
| パターン | 起きやすい構成 | 引き金 |
|---|---|---|
| A | 起きやすい構成mcp-remote経由のリモートサーバー | 引き金OAuth検出・プロキシ経由・TLSのハンドシェイクが60秒を超える |
| B | 起きやすい構成npx起動のローカルstdioサーバー | 引き金npmレジストリの証明書検証リトライ(UNABLE_TO_VERIFY_LEAF_SIGNATURE)で起動が遅延 |
別の報告者は、npxもmcp-remoteも使わない自作の.mcpb拡張機能(node直起動のサーバー)で同じ「Connection closed」「Request timed out」に遭遇しています。同じ設定はClaude Code CLIからは問題なく動作し、Desktop側だけで失敗しました。
この環境のログにはEra probe verdict: legacy (sibling did not complete the exchange)という行が残っていました。報告者はこの行を、プールが「もう一つの待機セッション(sibling)」からの応答を待って準備完了を保留する内部処理を指すものと読み、実際には該当する2つ目のセッションが存在しないまま待ち続けていたのではないかと推測しています。エラー文言の「Cowork and Code sessions」という複数形も、実在する2つ目の利用者を示す証拠ではなく、この待機処理に付いた固定ラベルにすぎないというのが報告者の結論です。この報告はissueの最終コメント(2026年9月16日付)でも未解決のまま残っており、60秒ゲート自体がパターンA・Bとは独立に壊れている可能性を示しています。
対処法 — npx経由の起動をやめてインストール済み実行ファイルを直接指定する
パターンBに該当した報告者は、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": []
}この変更で初期化応答は90秒超のタイムアウトから0.124秒まで短縮されました。mcp-remote経由のConfluence・Jira・GitHubサーバーも同じ考え方で、node.exeからインストール済みのmcp-remoteパッケージを直接呼び出す構成に変更しています。再起動後は5台すべてが接続に成功し、それ以降のプールタイムアウトはゼロになりました。変更前は8日間で約103回発生していた不具合です。
npxはサーバーが未インストールなら毎回npmレジストリに問い合わせるため、企業プロキシ配下では証明書検証のリトライが起動時間を押し上げます。すでにローカルにインストール済みのパッケージへ直接パスを通すことで、この問い合わせ自体を避けられます。
それでも直らないケースが残っている
npmの証明書検証で説明できたのは、報告者1人の環境だけです。もう一方の.mcpb拡張機能のケースはnpxもOAuthも経由しない構成で、同じ症状が再現しました。issueのコメント主は、npx・プロキシ経由の遅延は引き金の一つに過ぎず、固定60秒のゲートそのものが共通の欠陥だという見立てで、issueをオープンのまま残しています。
対処法を試しても直らない場合は、mcp-server-<name>.logを開き、接続成功のログ(Server started and connected successfullyやProxy established)が「Not ready after 60 seconds」より前に出ているか後に出ているかを確認してください。後に出ているなら、この記事と同じ不具合です。公式のWindows向けトラブルシューティングでは設定の確認・アプリの再起動・タスクマネージャーでのプロセス確認・サーバーログの確認が案内されていますが、この共有プールの不具合そのものには触れていません。
企業ネットワーク環境では、プロキシやDLP(Data Loss Prevention)アプライアンスを原因と疑いたくなりますが、原因と決めつける前に確認が要ります。今回の報告環境でも、DLPアプライアンスが別のAPIエラーを断続的に出していました。ただしshared-poolのタイムアウトは8日間で約103回発生していたのに対し、DLPエラーは19回だけで、大半のタイムアウトはDLPエラーと時間的に重なっていませんでした。プロキシやDLPを止めて検証する前に、まず両方のログのタイムスタンプを突き合わせ、本当に連動しているかを確認する方が早く切り分けられます。
この「60秒」とCLIのMCP_TIMEOUTは別物
Claude Code CLIにもMCPの60秒に関わる設定がありますが、仕組みが違います。MCP_TIMEOUT環境変数は本来、CLIがMCPサーバーの起動を待つタイムアウト(起動タイムアウト)を設定するもので、たとえばMCP_TIMEOUT=10000 claudeのように指定します。HTTP・SSE・claude.aiコネクタのMCPサーバーに限っては、このMCP_TIMEOUTが二次的な用途にも使われます。最初のレスポンスバイトが届くまでのper-requestタイマーを「60秒・そのサーバーのtimeout・MCP_TIMEOUTのうち最大値」で決める仕様です。
これはサーバーが接続済みになったあと、個々のツール呼び出しにかかる制限です。stdio・WebSocketのサーバーにはこのper-requestタイマー自体がありません。一方、今回のDesktopの「Not ready after 60 seconds」は接続の準備段階、しかもDesktopアプリ内部の起動プール固有の話です。どちらもCLI側の設定であることに変わりはありませんが、issueのスレッドではMCP_TIMEOUTを伸ばしてDesktopの共有プールの60秒を延ばせたという報告はありません。
MCPサーバーの一般的な設定・スコープ・タイムアウト調整はClaude Code MCP設定ガイドにまとめています。claude mcp add-from-claude-desktopで一部のサーバーだけ取り込みに失敗する別のエラーはCould not import a serverエラーを参照してください。DesktopとCLIで環境変数の引き継ぎ方が違う可能性も調査の過程で検討されたので、stdioサーバーへの環境変数の扱いはCLAUDE_CODE_MCP_ALLOWLIST_ENVとはも参考になります。