# Title Local MCP servers fail with "Not ready after 60 seconds" / "Request timed out" even though the remote connection succeeds (shared-pool readiness bug) # Environment - App: Claude Desktop (Cowork build), Windows 11 Enterprise - Update channel: `autoUpdatesChannel: "latest"` (auto-updates enabled) - Config: 5 local MCP servers defined in `claude_desktop_config.json` (3 remote via `mcp-remote` + 2 local stdio: playwright, context7) - Network: corporate proxy (reachable, verified via `Test-N

Local MCP servers fail with 'Not ready after 60 seconds' even though the remote connection succeeds (shared-pool readiness bug)

Status Open

Maintainer reply None cached

Activity 13 comments · opened Sep 8, 2026

Title

Local MCP servers fail with "Not ready after 60 seconds" / "Request timed out" even though the remote connection succeeds (shared-pool readiness bug)

Environment

App: Claude Desktop (Cowork build), Windows 11 Enterprise
Update channel: autoUpdatesChannel: "latest" (auto-updates enabled)
Config: 5 local MCP servers defined in claude_desktop_config.json (3 remote via mcp-remote + 2 local stdio: playwright, context7)
Network: corporate proxy (reachable, verified via Test-NetConnection), internal domain reachable directly in browser

Summary

All 5 configured local MCP servers (confluence-mcp, jira-mcp, github-mcp, playwright, context7) suddenly started failing this morning with no config changes since the previous day, when all 5 were working. The same MCP configs work correctly via the claude CLI (Claude Code) on the same machine at the same time, ruling out network/proxy/token/cert issues.

Steps to reproduce

Configure any MCP server via mcpServers in claude_desktop_config.json (works fine one day)
Restart the app (auto-update likely applies here)
Open Settings → 계정 → 로컬 MCP 서버 — all servers show ⚠️ 실패 with "Couldn't start for Cowork and Code sessions. Error: Request timed out"
In parallel, run claude mcp list in a terminal with the identical server definitions — all connect successfully (✔ Connected)

Expected behavior

Local MCP servers configured in claude_desktop_config.json connect successfully, consistent with the claude CLI behavior using the same config.

Actual behavior

Per %LOCALAPPDATA%\Claude\Logs\mcp-server-confluence-mcp.log, the underlying mcp-remote process actually succeeds in connecting to the remote server:

[27284] Connected to remote server using StreamableHTTPClientTransport
[27284] Local STDIO server running
[27284] Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport

But shortly after, the app's internal session-pool layer reports a timeout and shuts the server down before the UI/session ever sees it as ready:

[info] Server transport closed (renderer released port); shutting down server
[error] Couldn't start for Cowork and Code sessions. Error: Not ready after 60 seconds; the sessions waiting for it started without it { metadata: { context: 'shared-pool', ... } }
[error] Couldn't start for Cowork and Code sessions. Error: Request timed out { metadata: { context: 'shared-pool', ... } }

This indicates the underlying connection succeeds, but the app's shared MCP-process-pool coordination (used across Cowork/Code sessions in the same app) fails to propagate the "ready" signal within its 60s window, and reports a false failure to the UI.

Notes

This reproduces identically for all 5 configured servers (3 remote HTTP via mcp-remote, 2 local stdio), suggesting the bug is in the shared-pool layer itself rather than any individual server's transport/auth.
Fully quitting (including tray icon) and relaunching the app did not resolve it.
Suspect this coincides with an overnight auto-update (autoUpdatesChannel: "latest"), since nothing in the local config changed between the last known-good state and this failure.

Attachments

(attach a redacted excerpt of mcp-server-confluence-mcp.log around the failure timestamp — double-check no x-auth/Authorization header values are present before attaching)

View original on GitHub ↗

3 Comments

Thesideofjustice · 1 month ago

Log excerpt: mcp-server-confluence-mcp.log (last 200 lines, most recent failure cycle)

Note: header names (e.g. x-auth) appear but values/tokens are never logged by mcp-remote, so this excerpt is safe to share as-is.

      'C:\\Knox Drive',
      'C:\\Knox Drive\\vcredist64',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Microsoft\\WindowsApps\\',
      'C:\\Program Files\\nodejs\\',
      'C:\\Program Files\\Microsoft VS Code\\bin',
      'C:\\PortableGit',
      'C:\\Users\\hyunjin80.park\\.local\\bin',
      'C:\\Program Files\\GitHub CLI\\',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Programs\\Python\\Python313\\',
      'C:\\Program Files\\Eclipse Adoptium\\jdk-25.0.1.8-hotspot\\bin',
      'C:\\apache-maven-3.9.11\\bin',
      'C:\\ProgramData\\chocolatey\\bin',
      'C:\\gradle-9.2.1\\bin',
      'C:\\Users\\hyunjin80.park\\AppData\\Roaming\\npm',
      'C:\\Python314',
      'C:\\Python314\\Scripts',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Programs\\Kiro\\bin',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\ClaudeBin',
      'C:\\Users\\hyunjin80.park\\Documents\\Codex\\bin',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Kiro-Cli\\',
      [length]: 37
    ]
  }
} %o
2026-09-08T01:10:31.925Z [confluence-mcp] [info] Server started and connected successfully { metadata: undefined }
2026-09-08T01:10:33.357Z [confluence-mcp] [info] Message from client: method="initialize" id=0 params { metadata: undefined }
2026-09-08T01:10:35.225Z [confluence-mcp] [info] Shutting down server... { metadata: undefined }
2026-09-08T01:10:35.225Z [confluence-mcp] [info] Client transport closed { metadata: undefined }
2026-09-08T01:10:35.225Z [confluence-mcp] [info] Server transport closed (intentional shutdown) { metadata: undefined }
2026-09-08T01:10:35.225Z [confluence-mcp] [info] Client transport closed { metadata: undefined }
2026-09-08T01:10:39.258Z [confluence-mcp] [info] Initializing server... { metadata: undefined }
2026-09-08T01:10:39.258Z [confluence-mcp] [info] Era probe verdict: legacy (exec lane pinned — no sibling probe) { metadata: undefined }
2026-09-08T01:10:39.308Z [confluence-mcp] [info] Using MCP server command: C:\WINDOWS\System32\cmd.exe with path: {
  metadata: {
    paths: [
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Programs\\Python\\Python313',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Programs\\Python\\Python311',
      'C:\\Program Files\\nodejs',
      'C:\\Program Files\\Git\\cmd',
      'C:\\Program Files\\Git\\mingw64\\bin',
      'C:\\WINDOWS\\system32',
      'C:\\WINDOWS',
      'C:\\WINDOWS\\System32\\Wbem',
      'C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\',
      'C:\\WINDOWS\\System32\\OpenSSH\\',
      'C:\\Program Files (x86)\\Citrix\\HDX\\bin\\',
      'C:\\Program Files\\Citrix\\HDX\\bin\\',
      'C:\\windows\\System32\\WindowsPowerShell\\v1.0\\',
      'C:\\windows\\System32\\Wbem',
      'C:\\Program Files\\Zulu\\zulu-8\\bin\\',
      'C:\\Program Files\\dotnet\\',
      'C:\\Knox Drive',
      'C:\\Knox Drive\\vcredist64',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Microsoft\\WindowsApps\\',
      'C:\\Program Files\\nodejs\\',
      'C:\\Program Files\\Microsoft VS Code\\bin',
      'C:\\PortableGit',
      'C:\\Users\\hyunjin80.park\\.local\\bin',
      'C:\\Program Files\\GitHub CLI\\',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Programs\\Python\\Python313\\',
      'C:\\Program Files\\Eclipse Adoptium\\jdk-25.0.1.8-hotspot\\bin',
      'C:\\apache-maven-3.9.11\\bin',
      'C:\\ProgramData\\chocolatey\\bin',
      'C:\\gradle-9.2.1\\bin',
      'C:\\Users\\hyunjin80.park\\AppData\\Roaming\\npm',
      'C:\\Python314',
      'C:\\Python314\\Scripts',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Programs\\Kiro\\bin',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\ClaudeBin',
      'C:\\Users\\hyunjin80.park\\Documents\\Codex\\bin',
      'C:\\Users\\hyunjin80.park\\AppData\\Local\\Kiro-Cli\\',
      [length]: 37
    ]
  }
} %o
2026-09-08T01:10:44.467Z [confluence-mcp] [info] Server started and connected successfully { metadata: undefined }
2026-09-08T01:10:44.479Z [confluence-mcp] [info] Message from client: method="initialize" id=0 params { metadata: undefined }
2026-09-08T01:10:44.800Z [confluence-mcp] [info] Server transport closed { metadata: undefined }
2026-09-08T01:10:44.800Z [confluence-mcp] [info] Client transport closed { metadata: undefined }
2026-09-08T01:11:37.095Z [confluence-mcp] [error] Couldn't start for Cowork and Code sessions. Error: Not ready after 60 seconds; the sessions waiting for it started without it { metadata: { context: 'shared-pool', stack: undefined } }
2026-09-08T01:11:37.454Z [confluence-mcp] [error] Couldn't start for Cowork and Code sessions. Error: Request timed out { metadata: { context: 'shared-pool', stack: undefined } }
2026-09-08T01:11:44.473Z [confluence-mcp] [info] Message from client: method="notifications/cancelled" params { metadata: undefined }
2026-09-08T01:11:44.474Z [confluence-mcp] [info] Client transport closed { metadata: undefined }
2026-09-08T01:11:44.474Z [confluence-mcp] [info] Server transport closed (renderer released port); shutting down server { metadata: undefined }
2026-09-08T01:11:44.474Z [confluence-mcp] [info] Shutting down server... { metadata: undefined }
2026-09-08T01:11:44.474Z [confluence-mcp] [info] Client transport closed { metadata: undefined }
[27284] Using callback port derived from the server URL: 20389
[27284] Using custom headers: x-auth
[27284] Discovering OAuth server configuration...
[27284] [27284] Connecting to remote server: https://sdsdev.co.kr/mcp-confluence/mcp
[27284] Using transport strategy: http-first
[27284] Connected to remote server using StreamableHTTPClientTransport
[27284] Local STDIO server running
[27284] Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport
[27284] Press Ctrl+C to exit
[27284] [Local→Remote] initialize
[27284] {
  "jsonrpc": "2.0",
  "id": 0,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "extensions": {
        "io.modelcontextprotocol/ui": {
          "mimeTypes": [
            "text/html;profile=mcp-app"
          ]
        }
      }
    },
    "clientInfo": {
      "name": "local-agent-mode-confluence-mcp (via mcp-remote 0.8.3)",
      "version": "1.0.0"
    }
  }
}
[27284] [Local→Remote] notifications/cancelled
[27284] 
Shutting down...
[27640] Using callback port derived from the server URL: 20389
[27640] Using custom headers: x-auth
[27640] Discovering OAuth server configuration...
[27640] [27640] Connecting to remote server: https://sdsdev.co.kr/mcp-confluence/mcp
[27640] Using transport strategy: http-first
[27640] Connected to remote server using StreamableHTTPClientTransport
[27640] Local STDIO server running
[27640] Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport
[27640] Press Ctrl+C to exit
[27640] [Local→Remote] initialize
[27640] {
  "jsonrpc": "2.0",
  "id": 0,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "extensions": {
        "io.modelcontextprotocol/ui": {
          "mimeTypes": [
            "text/html;profile=mcp-app"
          ]
        }
      }
    },
    "clientInfo": {
      "name": "claude-ai (via mcp-remote 0.8.3)",
      "version": "0.1.0"
    }
  }
}
[27640] [Local→Remote] notifications/cancelled
[27640] 
Shutting down...
2026-09-08T01:14:53.359Z [confluence-mcp] [info] Server transport closed { metadata: undefined }
2026-09-08T01:14:53.359Z [confluence-mcp] [info] Client transport closed { metadata: undefined }
2026-09-08T01:33:40.835Z [confluence-mcp] [error] Couldn't start for Cowork and Code sessions. Error: Not ready after 60 seconds; the sessions waiting for it started without it { metadata: { context: 'shared-pool', stack: undefined } }
2026-09-08T01:33:40.977Z [confluence-mcp] [error] Couldn't start for Cowork and Code sessions. Error: Request timed out { metadata: { context: 'shared-pool', stack: undefined } }
[11852] Using callback port derived from the server URL: 20389
[11852] Using custom headers: x-auth
[11852] Discovering OAuth server configuration...
[11852] [11852] Connecting to remote server: https://sdsdev.co.kr/mcp-confluence/mcp
[11852] Using transport strategy: http-first
[11852] Connected to remote server using StreamableHTTPClientTransport
[11852] Local STDIO server running
[11852] Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport
[11852] Press Ctrl+C to exit
[11852] [Local→Remote] initialize
[11852] {
  "jsonrpc": "2.0",
  "id": 0,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "extensions": {
        "io.modelcontextprotocol/ui": {
          "mimeTypes": [
            "text/html;profile=mcp-app"
          ]
        }
      }
    },
    "clientInfo": {
      "name": "local-agent-mode-confluence-mcp (via mcp-remote 0.8.3)",
      "version": "1.0.0"
    }
  }
}
[11852] [Local→Remote] notifications/cancelled
[11852] 
Shutting down...

stonianua · 1 month ago

Helpful split in the report: CLI claude mcp list shows Connected while Desktop's shared-pool path times out after the child already logged a successful transport. That usually means readiness is being judged on a different signal than "child process started / remote handshake OK."

Things that have helped isolate this class of shared-pool false fail on Windows:

Timestamp the pool error vs child log — if Proxy established successfully / Connected to remote server appears before Not ready after 60 seconds, the gate is almost certainly waiting on an in-app ready event that never fires (or fires on a different session id), not on network/auth.
Reduce fan-in — temporarily leave only one stdio server enabled and restart Desktop fully (quit tray too). If a single local stdio server still fails while CLI works, that strengthens the shared-pool regression vs a slow mcp-remote cold start eating the 60s budget across five servers.
Watch for double spawn — after an auto-update, some builds leave an orphaned MCP child holding the port; the new pool waiter then never sees ready. Check Task Manager for leftover node/mcp-remote from the previous Desktop process before relaunch.
Compare env inheritance — Desktop's pool may not pass the same proxy/NODE_EXTRA_CA_CERTS env the CLI shell has. If only the three mcp-remote servers fail while native stdio (playwright/context7) succeed under the single-server test, lean that way; if all five fail identically, pool coordination is still the prime suspect.

Redacting Authorization / cookie headers from the attached mcp-server log before upload is the right call — the useful lines are the transport success + the shared-pool timeout metadata, not the headers.

Thesideofjustice · 1 month ago

Update: re: @stonianua's diagnostic tips (1) and (4)

Thanks for the detailed breakdown — here's what we found re-examining the original log and running a partial version of the "reduce fan-in" test.

Re (1) timestamp comparison: Confirmed exactly the pattern you flagged. In the originally attached log:

01:10:44.800Z  Server transport closed (client disconnected almost immediately)
01:11:37.095Z  [error] Not ready after 60 seconds; the sessions waiting for it started without it
01:11:37.454Z  [error] Request timed out
──(only after this)──
[27284] Connected to remote server using StreamableHTTPClientTransport
[27284] Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport

The actual remote handshake succeeds, but strictly after the shared-pool's 60s gate already reported failure to waiting sessions. So this isn't "gate waits on the wrong signal never firing" — the right signal does fire, just too late.

Re (4) env inheritance vs. cold-start latency: Ran a rough version of the single-server test (imperfect — renaming server keys to "_disabled_X" doesn't actually stop them from being attempted, it just renames them, so all 5 were still attempted). Even so, in that run:

context7 (local stdio, direct npx) → started successfully
confluence-mcp (remote via mcp-remote) → still failed with the same "Not ready after 60 seconds" error

Combined with (1), our read is this is less likely a proxy/NODE_EXTRA_CA_CERTS env-inheritance gap (which would typically cause a hard failure, not an eventual success) and more likely: remote servers routed through mcp-remote have a cold-start path (OAuth discovery + proxy negotiation + TLS to the remote endpoint) that's slow enough to blow through whatever fixed budget the shared-pool readiness gate uses, while local stdio servers spawn fast enough to always clear it.

If that's right, possible directions: extend/make configurable the shared-pool readiness timeout for mcp-remote-backed servers specifically, or have the pool accept a "still connecting, don't give up" heartbeat from mcp-remote instead of a hard 60s cutoff.

Happy to run a cleaner single-server test (actually removing the other 4 entries rather than renaming) if useful — didn't want to spend more cycles on it without a signal this is helpful for triage.

Showing cached comments. Read the full discussion on GitHub ↗