/research web search fails instantly (web-search-unavailable) with custom GitHub App auth
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- bun, github, typescript
- Área
- ai, authentication, backend
Línea de trabajo
Trace credential.token from apps/server/src/agent/active-owner.ts through apps/server/src/jobs/research-workspace.ts into the createMCPClient call in apps/server/src/harness/web-search.ts. Reproduce with the provided ghu_ versus gho_ comparison, and confirm whether GitHub's Copilot MCP endpoint supports App user tokens before changing token selection or documentation. Done means the failing path and actual throw site are identified, with either a verified fix and regression coverage or a documented custom-GitHub-App limitation.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
/research web search consistently fails with web-search-unavailable on a fresh self-hosted instance using a custom (non-GitHub-owned) GitHub App for sign-in, even though the signed-in account has an active, working Copilot entitlement. Diagnosis points to the GitHub App user access token (ghu_...) not being accepted by GitHub's Copilot MCP endpoint, while a classic OAuth token (gho_...) for the same account works against that same endpoint.
Environment
- Commit:
d9aec4befa397d6da9a1f483e634794a949f821f(2026-10-17) HARNESS=copilot-sdk,AGENT=on,BACKGROUND_JOBS=on,WEB_RESEARCH=on- Local dev setup per README ("Run locally"), Docker Postgres, Bun 1.4.2
- Custom GitHub App created per README's "Register these local URLs" instructions, with the documented repository permissions (Contents RW, PRs RW, Workflows RW, Checks/Commit statuses/Issues RO)
- GitHub account has an active Copilot plan (confirmed at github.com/settings/copilot: included credits in use, "Copilot can search the web" enabled, MCP servers enabled, Copilot CLI enabled)
Steps to reproduce
- Stand up Chopin locally against a fresh custom GitHub App (not GitHub's own hosted app).
- Sign in, create a channel on a repository, open a document.
- Trigger
/researchwith any brief. - Observe the research card fail with "Research failed... The public web-search service was unavailable."
- Retry — fails again, consistently, in ~1–12ms (not the ~60s timeout described in
docs/conversation-research.md).
Server-side diagnostics
Background job log for each attempt:
chopin: background job research-evidence <id> attempt 1 progress {"stage":"public-web","phase":"authorizing",...,"elapsedMs":0}
chopin: background job research-evidence <id> attempt 1 progress {"stage":"public-web","phase":"connecting-web",...,"elapsedMs":6}
chopin: background job research-evidence <id> attempt 1 failed - JobExecutionError: Background job execution failed: web-search-unavailable. diagnostic={"stage":"public-web","phase":"connecting-web",...}
The failure happens almost instantly (single-digit to low double-digit ms), every time, at the connecting-web phase — not the slow/variable web-search-timeout failure mode described in docs/conversation-research.md's "Live execution check" note. This looks like a fast rejection, not a hang.
Ruled out
- Copilot entitlement: confirmed active on the GitHub account (github.com/settings/copilot).
- Network reachability:
curltohttps://api.githubcopilot.com/mcp/from the same host succeeds and returns the expected401/WWW-Authenticateresponse when unauthenticated. - Debug instrumentation: added
console.errorto both catch blocks inapps/server/src/harness/web-search.ts(around thecreateMCPClientcall and around theclient.tools()call) and restarted thebun --watchdev server. Despite reproducing the failure multiple times afterward, neither log line appeared in server output — so the actual throw site may not be where I expected, and this is worth a maintainer's look at the exact code path under currentmain.
Working comparison
A manual MCP initialize handshake directly against the same endpoint, using a classic OAuth token (gho_..., obtained via gh auth token for the same GitHub account) succeeded immediately:
curl -X POST https://api.githubcopilot.com/mcp/ \
-H "Authorization: Bearer $(gh auth token)" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "X-MCP-Readonly: true" \
-H "X-MCP-Toolsets: web_search" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"diag","version":"0.0.1"}}}'
→ 200 OK, full initialize response with tools capability and an mcp-session-id.
Hypothesis
apps/server/src/jobs/research-workspace.ts / apps/server/src/harness/web-search.ts authorize the web_search MCP call using credential.token, which (per apps/server/src/agent/active-owner.ts) is owner.access.token — the GitHub App user access token (ghu_... prefix) issued through the App's own OAuth flow, per docs/authentication.md's description ("It acts as each signed-in user, with their App user access token, so repository-role checks and Copilot entitlement stay theirs").
Given a classic OAuth token for the same account/same Copilot entitlement works against api.githubcopilot.com/mcp/, but the App-issued token path fails instantly and consistently, it looks like GitHub's Copilot MCP endpoint may not accept GitHub App user access tokens (ghu_) the same way it accepts classic OAuth App tokens (gho_) — independent of the underlying user's Copilot entitlement. If so, this would mean /research's web-search step cannot work for any self-hosted deployment using a custom (non-GitHub-owned) GitHub App, regardless of configuration, which seems worth confirming and documenting (or fixing, if there's an alternate token/exchange Chopin should be using instead).
Suggested next steps for a maintainer
- Confirm whether
api.githubcopilot.com/mcp/is expected to acceptghu_-prefixed GitHub App user access tokens at all. - If not, document this as a known limitation for self-hosted instances with custom GitHub Apps (the README's "Run locally" section doesn't currently flag this).
- If it should work, there may be a bug in token selection/propagation for the
webSearchToolcall path — happy to help narrow this down further (e.g. by decrypting a real stored session token for a controlled test) if useful.
Happy to provide more diagnostic detail, logs, or test further on request.
- Lenguaje dominante
- TypeScript
- Estrellas
- 409
- Forks
- 24
- Merge medio
- 11 h 58 min
- PR fusionados (30 d)
- 456
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de githubnext/chopin
-
documentation triage/human-response
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
githubnext/chopin#149 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 3/5 Medio día Aptitud para principiantes 45/100
githubnext/chopin#597 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
githubnext/chopin#596 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 12/100
githubnext/chopin#595 ·
Los mantenedores suelen responder en 1 día
-
enhancement triage/human-response
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
githubnext/chopin#203 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de githubnext/chopin
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Renaming a projectAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
equinor/prisma-decision-web#927 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
bigbluebutton/bigbluebutton#26166 ·
Los mantenedores suelen responder en 1 día