High CPU and repeated "gh auth token" failures when not signed in (worse without gh) #5256

Describe the bug

When Copilot CLI runs without a usable GitHub credential, the background auth probe copilot_runtime::auth::gh (i.e. gh auth token) is retried in a tight loop with no backoff. I hit this in a normal interactive session using a BYOK provider, with no GitHub account signed in: the process sat with a CPU core pegged while I was working in that session, and signing in (/login) brought it back to idle immediately. The faster the probe fails, the worse it gets — where gh is not resolvable on PATH every attempt fails in microseconds and the process busy-spins at ~145 % of one core; with gh installed but signed out it still spins at ~19 %.

Every attempt logs:

[WARNING] [rust:copilot_runtime::auth::gh] Failed to run `gh auth token` {"error":"program path has no file name","program":""}

Note "program":"" — the probe is invoked with an empty program path, so no process is spawned and the caller retries at once. The warning rate equals the retry rate: 274 lines/s in the reproduction below (inter-arrival median 3 ms, min 0 ms).

Affected version

GitHub Copilot CLI 1.0.101.

Windows standalone binary via winget (GitHub.Copilot). gh was absent from PATH when variant A was measured, and installed but signed out (2.103.2) for variant B.

Steps to reproduce the behavior

How I ran into it: a normal interactive session using a BYOK provider, with no GitHub account signed in. CPU sat with one core pegged for as long as the session was open, and %USERPROFILE%\.copilot\logs\process-*.log filled up with the warnings above. Signing in via /login brought CPU back to idle.

Isolated experiment (measurement only, not the trigger): the essential condition is just a session with no GitHub credential. Without one the CLI would exit immediately, so to keep such a session alive on demand I pointed the BYOK provider at a port that refuses connections and ran it headless (-p). This setup exists only to make the spin measurable — it is not the scenario in the report.

$env:COPILOT_HOME              = "C:\temp\cp-empty"        # empty dir => no credentials
$env:COPILOT_PROVIDER_BASE_URL = "http://127.0.0.1:9/v1"   # refuses connections
$env:COPILOT_PROVIDER_API_KEY  = "sk-test"

copilot -p "say hi" -s --model gpt-4o-mini --no-auto-update

1. Run the block above with gh not on PATH (variant A).
2. Run it again with gh installed but not signed in (variant B).
3. Sample CPU per second: Get-Process copilot | Select-Object CPU.
4. Inspect %USERPROFILE%\.copilot\logs\process-*.log (or point --log-dir at a directory).

Result:

Three consecutive lines from variant A:

2026-10-26T07:23:17.891Z [WARNING] [rust:copilot_runtime::auth::gh] Failed to run `gh auth token` {"error":"program path has no file name","program":""}
2026-10-26T07:23:17.896Z [WARNING] [rust:copilot_runtime::auth::gh] Failed to run `gh auth token` {"error":"program path has no file name","program":""}
2026-10-26T07:23:17.899Z [WARNING] [rust:copilot_runtime::auth::gh] Failed to run `gh auth token` {"error":"program path has no file name","program":""}

Expected behavior

CPU should stay near idle during a session that has no GitHub credential — interactive or not — and an unresolvable gh binary should be treated as "gh unavailable": probed once, or on a backoff schedule, instead of being re-probed on every call.

Additional context

Environment

• OS: Windows 10 Enterprise LTSC 10.0.19044, x64
• Observed in an interactive session with a BYOK provider, no GitHub account signed in
• The figures come from the headless experiment above: same log signature, easier to sample
• No proxy configured

Earlier occurrence, same signature (first launch on this machine, 1.0.101, no login): 4,459 warnings in 37.0 s = 120.5 /s, median gap 7 ms, flat until the user signed in.

Notes on the mechanism

• The probe fails without spawning anything ("program":""), so retry latency is ~0 and the loop period collapses to microseconds.
• Failures appear to be retried immediately — no backoff, and the 0 ms inter-arrival gaps suggest overlapping attempts.
• Other auth probes settle at a ~1.1 s cadence while network-bound (auth::manager_orchestration: Failed to fetch GitHub CLI user login (401) ↔ Failed to fetch PAT user login (401)), so the gh-probe path is the outlier.
• With gh installed the loop is only slower (~19 % CPU), not gone.

Workaround

Signing in (/login) or exporting COPILOT_GITHUB_TOKEN / a fine-grained PAT stops the loop; installing gh only lowers the severity.

Possibly related (different root causes)

• High CPU usage in copilot-cli #4415 High CPU usage in copilot-cli
• Bug: Idle CLI sessions pin one CPU core at 100% (notify-rs debouncer loop busy-spins) #5148 Idle CLI sessions pin one CPU core at 100 % (notify-rs debouncer loop busy-spins)
• [High severity] 1.0.60 WSL2 regression: CLI MainThread spins at ~215% CPU while idle, TUI output frozen until restart (regression of #2208) #3700 [High severity] 1.0.60 WSL2 regression: CLI MainThread spins at ~215 % CPU while idle