Repository navigation
Desktop app: sessions die minutes after spawn — "GitHub credential registration is no longer available for this session" makes the github-mcp-server catalog stale and fatal #4905
Description
Environment
- GitHub Copilot desktop app 1.1.22 (commit
c3daa01), macOS arm64, bundled CLI 1.0.84-5 (server mode, stdio, Rust JSON-RPC engine) - Single github.com account signed in to the app;
gh auth status(bundledgh2.98.0, using the app-exportedGH_TOKEN) reports a valid token andgh issue list/gh repo viewsucceed with it - Standalone CLI 1.0.86 (
/opt/homebrew/bin/copilot) on the same machine/account is not affected
Summary
In desktop-app sessions the per-session GitHub credential registration that the CLI server's built-in github-mcp-server uses (dynamic header provider) disappears ~3–5 minutes after the CLI process spawns. github-mcp-server initialises fine at warm-up, but the first call to any of its tools (web_search, github-mcp-server-*) then fails with a header-provider error, the MCP tool catalog is marked stale, and every subsequent model turn fails until the session ends with session.end reason: error. Background sub-agents in the same process die with it. The app UI reports "you are no longer logged in to github-mcp-server" and links to the MCP list, but the built-in server is not listed there, so there is nothing the user can re-authenticate. Three full app restarts did not help.
Steps to reproduce
- Create a new worktree session in the desktop app and wait ~3 minutes.
- Ask the agent to call
web_search(or anygithub-mcp-server-*tool). - Observe the tool error, then repeated session errors on the following turns, then the session terminates.
Actual behaviour
Tool result:
MCP tool catalog changed before tool "github-mcp-server-web_search" could be invoked: Failed to verify cached MCP tools: MCP request failed: Transport send error: unexpected server response: dynamic header provider failed: GitHub credential registration is no longer available for this session
Followed by 5 × session.error:
Execution failed: Failed to refresh MCP tools for server github-mcp-server; the last catalog is stale
then session.end with reason: error — the CLI process exits and the worktree session is unusable.
CLI process log (~/.copilot/logs/process-<spawn>-<pid>.log, trimmed):
18:58:12.987Z [INFO] Starting CLI in server mode (stdio)
18:58:14.824Z [INFO] [rust:rmcp::service] Service initialized as client <- github-mcp-server OK at warm-up
18:58:44.524Z [INFO] Created session: db372b5f-…
19:01:02.593Z [WARNING] [rust:copilot_runtime::session::mcp::tool_catalog] Failed to list MCP tools for github-mcp-server; continuing with the previously listed tools: MCP request failed: Transport send error: Transport [mcp::client::ToolListRevisionTransport<…StreamableHttpClientWorker<…>>] error: unexpected server response: dynamic header provider failed: GitHub credential registration is no longer available for this session
… (30+ repeats until the session terminates)
Processes that never call github-mcp tools show the same root symptom non-fatally, from ~2 s after spawn, in the remote exporter:
[WARNING] [rust:remote::api_session_exporter] remote session batch flush failed {"error":"GitHub credential authority error: GitHub token provider registration \"<per-process uuid>\" is unavailable", …}
Expected behaviour
- The credential registration should remain valid for the lifetime of the CLI process, or be re-established on demand when the header provider needs it.
- A failed header refresh /
tools/listshould surface as a tool error only — it should not invalidate the catalog for unrelated model turns, and it must not terminate the session. - If the built-in server's auth is lost, the UI should offer a way to re-authenticate it (the current "no longer logged in" message points to an MCP list that does not contain the built-in server).
Timeline (UTC, 2026-09-18) — four sessions lost
| CLI process spawn | First failure | Δ |
|---|---|---|
| 18:07:08 | 18:10:06 | ~3 min |
| 18:11:56 | 18:15:36 | ~3.5 min |
| 18:38:57 | 18:43:46 | ~5 min |
| 18:58:12 | 19:01:02 | ~3 min |
The app's accounts.token_updated_at was rewritten at 18:11:42 — inside the failure window — yet the failures continued in processes spawned after that and after each of three app restarts (18:37:51, 18:38:19, 18:55:46).
Also observed 2026-09-16 08:12 (app 1.1.21).
Possible regression: on 2026-09-08 (app 1.1.15) the identical dynamic header provider failed: GitHub credential registration is no longer available for this session error occurred in a sub-agent, but it was a tool-level failure only — the session carried on. Since 1.1.21 the stale catalog is fatal. This looks like two issues: (a) registration loss (older), and (b) fatal stale-catalog handling (newer).
Ruled out
- Prompts/skills: reproduces with a bare
web_searchcall. - Token validity: the app-exported token works for
ghAPI calls; a standalonecopilot -p "…call web_search…" --allow-tool web_searchsucceeds in ~27 s from the same machine/account. - Project ↔ account link: the projects are Azure DevOps repos (
projects.github_account_idis NULL by design); this only affectscreate_issue, and the failures reproduce regardless. - App state: three app restarts, no change. App logs (
github-app.<pid>.log) contain no credential/token-provider entries at the failure times. - Other MCP servers (Azure DevOps stdio, Context7/Microsoft Learn HTTP) keep working in the same sessions.
Impact: any agent workflow that touches web_search or github-mcp-server-* in a desktop-app session is currently unusable; the standalone CLI is the only workaround.
Logs
Full CLI process logs for all four failed sessions plus the non-fatal exporter variant, and the app logs, are available — happy to share them privately on request.
Activity
JamesFescoAVB commentedon Sep 18, 2026
Independent Windows reproduction confirming this is cross-platform and not limited to worktree/child-agent sessions.
Environment
JamesFescoAVB, )Observations
github-mcp-server-search_codefailed withGitHub credential registration is no longer available for this session; shortly afterward the runtime removed the GitHub/Atlassian/web-search MCP tools from the active catalog.HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,GH_TOKEN, orGITHUB_TOKENvariables are configured.GH_TOKENappears only in the app-created process environment.%LOCALAPPDATA%\Copilot\mcp-toolsGitHub catalog is valid/current and contains the expected six tools. The failure occurs at dynamic credential/header refresh, not JSON catalog parsing.authoritative account credentialfor Git operations, which may be relevant to the shared credential lifecycle.This Windows evidence matches the reported fatal stale-catalog behavior. Heavy agent/skill usage appears to make the impact more frequent, but is not the root prerequisite.
jzm0720 commentedon Sep 18, 2026
100% happening to me the last few days. Seems like a new issue with the latest release. Frustrating for sure!
JamesFescoAVB commentedon Sep 18, 2026
I had to switch over to the CLI version. It's working for me, sees my sessions and my agents / skills, but it's not as easy to navigate as the standalone tool. The standalone requires a restart every 10 minutes or so, unworkable for a large task with many subagents.
palewire commentedon Sep 19, 2026
Also reproducing this on brand new sessions, not just after several minutes:
For me the "Execution failed: Failed to refresh MCP tools for server github-mcp-server; the last catalog is stale" error hits on the first tool call in a freshly opened chat — starting a new chat within the same running app instance doesn't reliably avoid it. A full quit-and-relaunch of the app sometimes helps temporarily, but the error comes back quickly, sometimes within the same session's first few tool calls. Given the root cause described here (per-session GitHub credential registration expiring 3-5 min after the CLI process spawns), it seems like in my case either the underlying CLI process is being reused/not actually fresh across "new chats," or the credential window is even shorter than 3-5 minutes for some sessions. Happy to grab logs if useful.
JamesFescoAVB commentedon Sep 24, 2026
I had reports that this was working better so, I made an attempt to use the standalone tool again and it started failing almost immediately, went back to the CLI for now. Running a healthcheck agent / skill I added, I was able to get these updated stats:
Mode: Periodic health check
Time window: 2026-09-24 08:52:52–14:52:52 PDT
Runtime and local-state checks
MCP catalog cache: 11 JSON catalogs parsed successfully; recent GitHub and Atlassian catalog entries were refreshed during the day. No cache corruption found.
OAuth token cache: Active token-cache files were present and recently refreshed; this points away from an absent cache and toward refresh/reconnect instability.
Environment leakage: No User/Machine-scoped
HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,NO_PROXY,GH_TOKEN,GITHUB_TOKEN, orCOPILOT_GITHUB_TOKENvalues found.Processes: Active
copilot.exe,github.exe, and language-server processes were present; no clearly stale process was identified by the check.Extensions:
splunk-logswas running normally.Versions: App
1.1.23; bundled CLI1.0.87-0. The current stable CLI release reported by GitHub was1.0.88, with1.0.89-*previews available.Burst/recency assessment: High. Failures continued until 14:45, and the registration warnings arrived as a tight same-second cluster. The events point to an active shared MCP/OAuth token-registration race or refresh failure, not isolated historical failures.
Risk level: High
Overall verdict: Active known issue detected. The desktop-app instability is consistent with upstream remote-MCP OAuth/token-refresh defects rather than a local proxy, cache, or environment configuration problem.
Matched upstream issues
Remote MCP (OAuth): expired access token forces interactive re-auth instead of silent refresh_token grant github/copilot-cli#4203 — Remote MCP OAuth token expiry requires re-authentication instead of silent refresh.
Process-local auth token stops refreshing; all prompts fail until restart github/copilot-cli#4929 — Process-local authentication token stops refreshing and prompts fail until restart.
Related credential/catalog failure family: Desktop app: sessions die minutes after spawn — "GitHub credential registration is no longer available for this session" makes the github-mcp-server catalog stale and fatal github/copilot-cli#4905
Related concurrent OAuth refresh failure: Concurrent MCP OAuth token-refresh for two servers cancels one reconnect (self-heals, but surfaces a false hard-failure error) github/copilot-cli#4842
Recommended action: Your choice to use the CLI is appropriate. Avoid relying on the desktop app for concurrent MCP-heavy work until the OAuth/transport defects are stabilized. If the app becomes unusable again, restart it or re-authenticate the affected MCP connection; do not delete caches or change environment settings as a first response.
Time window: 2026-09-24 08:52:52–14:52:52 PDT
kvnloo commentedon Sep 27, 2026
There are two failure domains here that seem worth separating.
A credential/header-provider failure should invalidate the authority lease, not destroy the last-known-good tool catalog and then kill unrelated turns. Catalog identity and credential freshness are different state.
I would test:
tools/listrefresh;A single credential authority with a generation/lease id would also make it possible to reject stale providers without turning the whole MCP graph into a fatal session error.
patniko commentedon Oct 26, 2026
Thanks for the report. We've shipped fixes in this area since this was filed (most recently in Copilot CLI v1.0.92), and we believe this may now be resolved. Could you retest on the latest release (Copilot CLI v1.0.103) and let us know whether you still see it? If we don't hear back in a couple of weeks, we may close this issue — you can always reopen it.
Triaged as part of a Copilot SDK backlog review, with help from GitHub Copilot.