Remote MCP server with slow "initialize" fails in Copilot CLI/app (Miro MCP: "server/discover" timeout, then "has no configured connection" after successful OAuth)

[rpstester]

Describe the bug

Remote MCP server with slow initialize fails in Copilot CLI/app but succeeds in VS Code (Miro MCP: server/discover timeout, then "has no configured connection" after successful OAuth)

The Miro remote MCP server (https://mcp.miro.com/) cannot be used from the Copilot CLI or the Copilot app, while the identical endpoint connects reliably from VS Code on the same machine, same network, and same corporate proxy.

When looking at the GHCP app MCPs, I see miro-mcp spin for a few seconds and then stop without a green check or anything.

Two distinct failures occur:

1. OAuth succeeds, reconnect fails. The browser auth popup appears and completes. The CLI prints ✓ Authentication Successful / Successfully authenticated with miro-cli, immediately followed by:

Authenticated, but failed to reconnect: Error: MCP server "miro-cli" failed to reconnect: MCP server "miro-cli" has no configured connection

No *.tokens.json is ever written to ~/.copilot/mcp-oauth-config, although a dynamic client registration record is written. Other OAuth MCP servers (azure-devops, msdocs) write token files normally.

2. Initialize times out. With a single clean Miro entry and stale OAuth records removed, sessions never initialize Miro at all. Logs show server/discover timed out; retrying with legacy initialize, and Miro tools are never loaded. Other configured servers initialize in the same session.

The root cause appears to be that Miro's initialize is slow. VS Code's MCP client waits and succeeds; its logs show it polling Waiting for server to respond to 'initialize' request... three times over ~18 seconds before discovering 48 tools. The Copilot Rust MCP client appears to give up earlier and fall back to legacy initialize, which never completes.

Affected version

GitHub Copilot CLI 1.0.88.

Steps to reproduce the behavior

• Add the Miro remote MCP server to ~/.copilot/mcp-config.json:

"miro-mcp": { "tools": ["*"], "type": "http", "url": "https://mcp.miro.com/", "headers": {} }

• Restart the Copilot CLI/app so the config loads cleanly.

• Trigger the Miro MCP connection (ask the agent to list Miro boards, or toggle the server in the app's MCP panel).

• Complete the browser OAuth flow when prompted.

• Observe the reconnect error, and/or check ~/.copilot/logs/process-*.log for server/discover timed out.

• Confirm no Miro *.tokens.json appears in ~/.copilot/mcp-oauth-config.

• For comparison, configure the same URL in VS Code mcp.json and start the server — it discovers 48 tools.

Expected behavior

The Copilot CLI/app should connect to https://mcp.miro.com/, persist the OAuth token, and load Miro's tools — matching VS Code's behavior against the same endpoint. Specifically, it should tolerate an initialize response that takes ~20 seconds, and after a successful OAuth it should reconnect to the server that was just authenticated rather than reporting "no configured connection."

Additional context

Relevant log lines:

[ERROR] [rust:rmcp::transport::worker] worker quit with fatal: Transport channel closed, when Client(OAuthChallenge { www_authenticate_header: "***\"https://mcp.miro.com/.well-known/oauth-protected-resource\"",
response: McpOAuthHttpResponse { status_code: 401, header_count: 14, has_body: true } })

[WARNING] [rust:mcp::client] server/discover timed out; retrying with legacy initialize 

VS Code log for the same endpoint, succeeding:

[info] Discovered resource metadata at https://mcp.miro.com/.well-known/oauth-protected-resource
[info] Discovered authorization server metadata at https://mcp.miro.com/.well-known/oauth-authorization-server
[info] Waiting for server to respond to `initialize` request...   (x3, ~18s total)
[info] Discovered 48 tools

[rpstester]

Update: the root cause isn't an initialize timeout. Our enterprise allowlist listed this server only by serverName (miro-mcp), and serverName entries aren't being honored (see #4989 ). After adding {"serverUrl": "https://mcp.miro.com"}, Miro connects in the app and CLI (1.0.89), finishing startup in about 5 seconds.

• server/discover timed out; retrying with legacy initialize isn't specific to Miro. It appears in sessions where Miro was blocked and never contacted, and the standard handshake succeeds afterward.

• The blank spinner was the policy block. It's logged only at DEBUG: Skipping MCP server "miro-mcp": not permitted by enterprise managed allow list.

Closing in favor of #4989 .