MCP: Cloudflare connection fails with "Subscription limit reached" after successful OAuth, then reports authentication required

[domgordon-MSFT]

Describe the bug

Cloudflare's remote MCP server fails to become available in Copilot CLI after successful OAuth authentication and protocol initialization. The runtime records:

MCP error -32603: Subscription limit reached

The MCP UI subsequently reports that the server requires authentication. Reauthenticating succeeds but leads to the same connection failure.

Evidence suggests an interoperability problem with notification subscriptions: Cloudflare intentionally rejects subscriptions/listen, and Copilot appears to treat this rejection as a fatal startup error rather than continuing without notifications. The actual outgoing RPC method was not captured, so this is a diagnosis supported by the server implementation and matching error, not a confirmed client-side call trace.

Affected version

GitHub Copilot CLI 1.0.89.

Environment: Windows, x64 distribution, PowerShell.
Observed on September 28, 2026.

Steps to reproduce the behavior

1. Configure the Cloudflare server in a workspace .mcp.json:

   {
     "mcpServers": {
       "cloudflare": {
         "type": "http",
         "url": "https://mcp.cloudflare.com/mcp",
         "tools": ["search", "execute"]
       }
     }
   }

2. Start Copilot CLI and authenticate with Cloudflare through the MCP UI.

3. Observe successful authentication and protocol initialization in the logs.

4. Observe MCP error -32603: Subscription limit reached immediately afterward. Cloudflare tools do not become available.

5. Open the server's tool listing. It reports:

   MCP server "cloudflare" requires authentication. Run `/mcp auth cloudflare` to authenticate.
   

6. Reauthenticate. The same sequence occurs.

The failure was observed repeatedly in two runtime logs, including immediately after successful reauthentication. This was not separately reproduced with a clean profile or a standalone authenticated RPC harness.

Expected behavior

If notification subscriptions are unavailable, the client should continue with ordinary tool discovery and calls where supported, without live tool-list updates.

If a subscription failure must be fatal, preserve the actual error rather than reporting an authentication requirement after successful authentication.

Additional context

Sanitized diagnostic excerpts

These are selected events from one connection attempt; unrelated events and the verbose initialization payload are omitted.

2026-09-28T22:47:42.601Z [ERROR] Successfully authenticated with cloudflare
2026-09-28T22:47:42.846Z [INFO] [rust:rmcp::service] Service initialized as client
2026-09-28T22:47:42.874Z [DEBUG] [rust:rt_mcp::native_host] Recorded failure for server cloudflare: MCP error -32603: Subscription limit reached {"server_name":"cloudflare"}
2026-09-28T22:47:42.874Z [WARNING] [rust:copilot_runtime::session::mcp::agent_host] MCP error -32603: Subscription limit reached {"server":"cloudflare"}
2026-09-28T22:47:54.185Z [WARNING] PluginsScreenDetail listMcpTools(cloudflare) failed: Error: MCP server "cloudflare" requires authentication. Run `/mcp auth cloudflare` to authenticate.

The successful initialization payload reports:

• Protocol version: 2026-07-28
• Server: cloudflare-api, version 0.1.0
• Tools capability: list_changed: Some(true)

The success event really is logged at ERROR severity; that is not a transcription mistake.

Relevant upstream implementation

Pinned to Cloudflare commit 259b2afc5aa84ce34461848d4fc36d817d49815e:

• MCP handler: passes { maxSubscriptions: 0 } to createMcpHandler. Its comment explicitly says the server publishes no change notifications and rejects subscriptions/listen to avoid long-lived streams.
• Modern MCP tests: the test named rejects subscriptions instead of opening a long-lived stream expects error code -32603 and message Subscription limit reached. Separate tests cover successful ordinary tools/list and tools/call requests.

This suggests the error is an intentional rejection of notification subscriptions, not an exhausted billing quota or evidence of invalid OAuth credentials. The advertised tool-list-change capability may also contribute to the interoperability problem.

Potential regression coverage: a server that initializes successfully, advertises tool-list changes, rejects subscriptions/listen with this error, but still supports tools/list and tools/call. Check that tools remain usable and authentication state is not incorrectly reported.

No credentials, account identifiers, or full logs are included.