Remote MCP calls to the Copilot-hosted GitHub MCP server fail (crush)

[jcberthon]

Describe the bug

Remote MCP calls to the Copilot-hosted GitHub MCP server (https://api.githubcopilot.com/mcp/) fail during tool listing with a "session not found" error, specifically on the subscriptions/listen request, which is sent with an empty session ID. This started abruptly today - first occurence at 2026/08/20 14:29:20 UTC+2 - with no local config or token changes, and reproduces consistently across multiple client (Crush) versions (0.88.1, 0.89.0 and 0.90.0), so it does not appear to be a client-side regression. I have been using the remote MCP calls for the past 2-3 weeks successfully.

Notably, the initialize response's capabilities.resources object is empty ({}) — no subscribe: true is advertised — yet the client attempts a subscriptions/listen call regardless, which then fails with the empty-session error and tears down the connection.

I've isolated this to the server/session layer with a manual curl reproduction (see below, and double check it as I asked my local AI to give me the curl commands for this investigation): a raw initialize -> notifications/initialized ->tools/list sequence against the same endpoint, with the same PAT, completes successfully and returns a valid session ID. This suggests the issue is specific to how the session ID is being handled/propagated for the subscriptions/listen call path, not with authentication or the basic MCP handshake.

Affected version

I don't know which version the remote is using. But I can see in this morning crush logs that it triggers no error, and then in the early afternoon and until now I have the errors. So whatever changed during that time period.

The curl initialise post returned a version, I hope this is relevant for you:

"version":"github-mcp-server/remote-cea154657bcbd68eeea95ecedde676a3278e2c30"

Steps to reproduce the behavior

1. Configure an MCP client (I used Crush, versions 0.90.0, 0.89.0, and 0.88.1, all reproduce identically) to connect to https://api.githubcopilot.com/mcp/ via HTTP transport with a valid PAT in the Authorization: Bearer header. (see below)
2. Have the client perform the standard MCP handshake (initialize → notifications/initialized → tools/list).
3. Observe the client fail while listing tools, with the underlying transport attempting subscriptions/listen and receiving a "session not found" error with an empty session ID.

I'm using the following .crushrc configuration in my local project:

mcp add github --type http --url "https://api.githubcopilot.com/mcp/" \
  --timeout 10 --header Authorization "Bearer $GH_PAT"

Before calling crush I load my GitHub PAT in the GH_PAT env variable. I'm using a fine grained access token (which is not expired):

Repository access: openporte/openporte
Repository permissions:  Read access to Dependabot alerts, License compliance alerts, code, code quality, commit statuses, issues, metadata, pull requests, and security events

Expected vs actual behavior

Expected: When starting crush, the MCP status for GitHub should be green.

Actual: When starting crush, the MCP status for GitHub is red with an error. The message is truncated in the TUI: GitHub error: connection cl... the rest isn't visible. But I have a log message which is in the next section.

Logs

This is the relevant line from my crush log (the first time it broke):

2026/08/20 14:29:20 ERRO Error listing tools error="connection closed: calling "tools/list": client is closing: sending "subscriptions/listen": failed to connect (session ID: ): session not found" source=github.com/charmbracelet/crush/internal/agent/tools/mcp/init.go:552

And the previous startup was successful with:

2026/08/19 02:34:32 INFO Initializing MCP clients source=github.com/charmbracelet/crush/internal/agent/tools/mcp/init.go:294

Crush was running the whole time between this two dates. I restarted crush this afternoon because I added a new provider to its config. In my crush sessions this morning and yesterday, I referenced GitHub issues which were read from crush.

And from curl, initialize response capabilities (redacted of unrelated fields):

{"capabilities":{"completions":{},"prompts":{},"resources":{},"tools":{}}, "protocolVersion":"2025-06-18"}

Note resources is empty; no subscribe flag advertised.

[CAOShurong]

Thanks for the detailed reproduction. I did a source-level check against the public repository:

• PR Reject unsupported subscription streams #3073 (merged 2026-08-17, commit 3085e59) already handles this unsupported method. For a request carrying Mcp-Method: subscriptions/listen, the server returns HTTP 404 / JSON-RPC -32601 instead of opening a session-backed SSE stream. The regression test covers matching, missing, and mismatched Mcp-Method; those cases pass locally, as does go vet ./pkg/http.
• The reported hosted build identifier github-mcp-server/remote-cea154657bcbd68eeea95ecedde676a3278e2c30 is not a public commit, so it is not possible to verify from public Git data whether that deployment contains Reject unsupported subscription streams #3073.
• Since the initialize response advertises capabilities.resources: {} (and no subscription support), a client should not start subscriptions/listen. The observed empty-session error is therefore consistent with either a hosted deployment that predates Reject unsupported subscription streams #3073 or a request path that is not sending the Mcp-Method header, rather than with PAT authentication or basic MCP handshake failure.

Could you capture one failing exchange with Authorization redacted, including the Mcp-Method request header and response status/body? In particular, comparing these will separate the two cases:

1. Mcp-Method: subscriptions/listen — expected 404 / -32601 on Reject unsupported subscription streams #3073.
2. Missing or mismatched Mcp-Method — expected SDK header-validation error.

If the header is present and the hosted server still returns session not found, the next action would be to verify/redeploy the remote image against #3073.

[ameyabapat-bsft]

We get similar error MCP::Client::RequestHandlerError: Internal error handling notifications/initialized request when trying to do notifications/initialized call on https://api.githubcopilot.com/mcp/ using API key. Does it support notifications/initialized or it is stateless server now that doesn't need notifications/initialized?