Skip to content

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

Description

@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.

Activity

  1. CAOShurong commented on Aug 23, 2026

    @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.

  2. ameyabapat-bsft commented on Aug 25, 2026

    @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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions