Process-local auth token stops refreshing; all prompts fail until restart

[NGloreous]

Describe the bug

A long-running Copilot CLI process permanently loses authentication. After the failure, every normal prompt and /ask immediately returns an authorization error. Running /login does not recover the process. Restarting and resuming the same session restores operation immediately.

The failure is process-local: several older concurrent CLI processes remained usable, and a newly launched process authenticated successfully. No COPILOT_GITHUB_TOKEN, GH_TOKEN, or GITHUB_TOKEN override was present.

The failing process first logged an expired/rejected GitHub MCP token almost exactly one hour after startup. It later logged 401 AuthenticateToken failed from the Copilot Tasks API. OAuth recovery attempted discovery against the enterprise Copilot endpoint but failed, leaving the process permanently unable to submit prompts.

Affected version

GitHub Copilot CLI 1.0.85 on Windows 11. The process was launched by a host application with --no-auto-update, --resume, and an additional MCP configuration.

Steps to reproduce

1. Start an interactive Copilot CLI session and keep it open while performing a long-running workflow.
2. Keep several other CLI sessions running concurrently.
3. After approximately one hour or longer, submit another prompt.
4. Observe that every prompt and /ask reports an authorization error.
5. Run /login; observe that the process remains broken.
6. Start a new CLI process; observe that it works immediately.
7. Restart/resume the failed process; observe that authentication works again.

Expected behavior

Short-lived service and MCP tokens should refresh automatically without interrupting the active workflow. If refresh fails, /login should reload the new credentials into the current process.

Actual behavior

The process retains unusable authentication state indefinitely and all model turns fail until the process is restarted.

Timeline and log evidence

• Process start: 2026-09-21 20:20:37 PDT
• GitHub MCP 401 invalid_token: 2026-09-21 21:21:01 PDT (1 hour, 24 seconds after startup)
• Copilot Tasks API 401 AuthenticateToken failed: 2026-09-21 22:05:48 and 22:09:33 PDT
• MCP resource: https://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp/readonly
• Failed OAuth metadata discovery: https://api.enterprise.githubcopilot.com/mcp/readonly
• Request IDs:
  • BE0F:221FB7:19F29C8:1DB6AF1:6AB20CAC
  • 633A:221FB7:1A2915E:1DF4EE8:6AB20D8D

A sanitized diagnostic excerpt is available. Raw conversation history and credentials have been excluded.

Related issues

• Session token expiry stops works flows, resuming fixes issue. #3763 — session token expiry stops workflows
• Remote MCP (OAuth): expired access token forces interactive re-auth instead of silent refresh_token grant #4203 — expired MCP OAuth token does not silently refresh
• Concurrent MCP OAuth token-refresh for two servers cancels one reconnect (self-heals, but surfaces a false hard-failure error) #4842 — MCP OAuth refresh/reconnect concurrency
• Session token expired. Please resend your message. #2818 — earlier one-hour session-token expiry issue, reported fixed in 1.0.35-3

Additional context

Current stable is newer than the affected installation. I will retest on the current stable version and update this issue, but this report captures a repeatable failure seen multiple times on 1.0.85.

[NGloreous]

Sanitized diagnostic evidence: https://gist.github.com/NGloreous/e8240b34325f006dfea03e608dede309

[NGloreous]

Additional evidence from a second occurrence on September 22, 2026:

Three separate interactive processes became unable to answer any prompt or /ask, while two other long-running processes continued answering successfully and a newly launched process worked immediately.

Common signature in all three affected processes

Each affected process repeatedly logged:

OAuthChallenge ... error="invalid_token"
resource_metadata="https://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp/readonly"
Connecting to github-mcp-server...
OAuth authentication failed for github-mcp-server:
Failed to discover authorization server metadata for
https://api.enterprise.githubcopilot.com/mcp/readonly

The challenge identifies the public api.githubcopilot.com resource, but recovery/discovery is attempted against api.enterprise.githubcopilot.com. No successful GitHub MCP reinitialization follows in the affected processes.

The failures run on a per-process hourly timer anchored to each process's startup minute:

Process	Started (PDT)	First failed MCP refresh (PDT)	Subsequent retries
A, resumed session	Sep 21 22:57	Sep 22 05:58	approximately every hour at :58
B	Sep 21 16:02	Sep 21 21:02	approximately every hour at :02
C	Sep 21 08:48	Sep 22 06:48	approximately every hour at :48

For process A, the final attempted user turn was persisted at 2026-09-22T17:29:11.607Z; its MCP invalid_token was logged at 2026-09-22T17:29:11.542Z, only 65 ms earlier. The turn has no assistant response. This strongly suggests that a foreground turn encountering the failed MCP refresh path is converted into the generic authorization error.

Process B similarly ended with a scheduled failed refresh at 17:02:52Z, followed by another failed refresh at 17:03:03Z when the user attempted a prompt. The failed prompt was not persisted as a completed turn.

Healthy comparison

Two known-working processes were still completing responses at 17:19Z and 17:47Z. Their logs show successful github-mcp-server client initialization against api.enterprise.githubcopilot.com and do not show the repeated invalid_token / failed-discovery sequence in their active log history.

All compared processes use CLI 1.0.85, the same signed-in account, the same host application version, --no-auto-update, and equivalent injected MCP server sets. No GitHub token environment override is set.

Correction to initial report

The Copilot Tasks API 401 AuthenticateToken failed appeared in the first observed incident but did not appear in the two new foreground failures. It is therefore not the common trigger. The strongest shared signal is the built-in GitHub MCP refresh attempting to reconcile a public-resource challenge with the enterprise endpoint, then poisoning/aborting the foreground turn.

This seems closely related to #4203 and #4842, but the impact here is broader: after the refresh failure, ordinary prompts and /ask are unusable until the process is restarted.