Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#3,129 2 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
go
Domaine
api, backend

Piste de recherche

Commencez par le handshake curl manuel et les points d’entrée de Crush MCP dans internal/agent/tools/mcp/init.go, en particulier les lignes journalisées autour de 552 et 294. Comparez la gestion des sessions pour subscriptions/listen avec la initialize capabilities response, puis reproduisez le problème sur l’endpoint distant. C’est terminé lorsque la liste des outils est obtenue sans erreur empty-session et que Crush signale un statut GitHub MCP vert.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug request ai review
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.

Langage dominant
Go
Étoiles
33.1k
Forks
5k
Merge moyen
1 j 8 min
PR mergées (30 j)
13

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de github/github-mcp-server

Toutes les issues de github/github-mcp-server

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.