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

Reproduce the failure in a desktop-app worktree session using web_search, then compare it with the standalone CLI. Start with ~/.copilot/logs/process--.log and the github-mcp-server credential-registration and tool-catalog paths described in the report. Done means credentials remain usable or refresh on demand, auth loss is isolated to a tool error, and the session does not terminate.

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 (bundled gh 2.98.0, using the app-exported GH_TOKEN) reports a valid token and gh issue list/gh repo view succeed 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

1. Create a new worktree session in the desktop app and wait ~3 minutes.
2. Ask the agent to call web_search (or any github-mcp-server-* tool).
3. 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

1. 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.
2. A failed header refresh / tools/list should surface as a tool error only — it should not invalidate the catalog for unrelated model turns, and it must not terminate the session.
3. 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_search call.
• Token validity: the app-exported token works for gh API calls; a standalone copilot -p "…call web_search…" --allow-tool web_search succeeds in ~27 s from the same machine/account.
• Project ↔ account link: the projects are Azure DevOps repos (projects.github_account_id is NULL by design); this only affects create_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.