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

从手动 curl 握手以及 internal/agent/tools/mcp/init.go 中的 Crush MCP 入口开始，重点查看 552 和 294 附近记录的日志行。将 subscriptions/listen 的会话处理与 initialize capabilities response 进行比较，然后针对远程端点重现问题。完成标准是工具列表获取成功且没有 empty-session 错误，并且 Crush 报告绿色的 GitHub MCP 状态。

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.