Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#3,129 2 comentários 1 reação 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
api, backend

Direção de pesquisa

Comece pelo handshake manual do curl e pelos pontos de entrada do Crush MCP em internal/agent/tools/mcp/init.go, especialmente as linhas registradas próximas a 552 e 294. Compare o tratamento de sessão de subscriptions/listen com a initialize capabilities response e, em seguida, reproduza o problema no endpoint remoto. Está concluído quando a listagem de ferramentas for bem-sucedida sem um erro empty-session e o Crush reportar um status verde do GitHub MCP.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
33.3k
Forks
5.1k
Merge médio
1d 1h
PRs com merge (30d)
19

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/github-mcp-server

Todas as issues de github/github-mcp-server

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.