Repository navigation
Startup error "Failed to read model provider attribution: Error: Not authenticated" in 1.0.89 #5008
Description
Describe the bug
Since 1.0.89, every new interactive session shows this error twice right after startup:
Failed to read model provider attribution: Error: Not authenticated
Sign-in completes about 3 seconds later and chat/model requests work normally. It looks like a startup race: the new provider-attribution code (model-picker and model-provider-labels) calls model.list() before authentication has finished and reports the failure as a session error.
Affected version
GitHub Copilot CLI 1.0.89
Steps to reproduce the behavior
- Authenticate via the
COPILOT_GITHUB_TOKENenvironment variable (OAuth token; no accounts stored via/login). - Start
copilotin a trusted directory. - The error appears twice in the timeline immediately after startup.
Timing from session events and the process log (relative to session.start):
+0.00s session.start
+0.29s session.error Failed to read model provider attribution: Error: Not authenticated
+0.31s session.error Failed to read model provider attribution: Error: Not authenticated
+3.04s [INFO] Signed in to https://github.com as <user>.
Expected behavior
No error at startup. Provider attribution should be loaded after authentication completes (or retried once signed in) instead of surfacing "Not authenticated".
Additional context
- OS / arch: macOS, x86_64 (darwin-x64 package)
- Shell: zsh
- Auth:
COPILOT_GITHUB_TOKENenvironment variable - The code path that emits this message is not present in 1.0.85-1.0.88; the error started after updating to 1.0.89.
- Impact appears cosmetic: the error shows on every new session, but chat and model calls work.
Activity
Tak2121 commentedon Sep 30, 2026
npechett-wtg commentedon Sep 30, 2026
yup need fix
norc-peterbrymer commentedon Sep 30, 2026
Having the same issue but with windows os
kenneth-burgener-sndk commentedon Sep 30, 2026
Additional data point: on Linux x64 (1.0.89) with stored credentials (not
COPILOT_GITHUB_TOKEN), this is intermittent rather than every session, and it tracks whether startup auth is warm or cold.Across 11 interactive launches on 1.0.89, the time from
Starting Copilot CLIto the first authenticated-account log line ([managedSettings] self-fetch starting for account https://github.com/...) was bimodal:model-provider-labelserrorsession.start)Cold launches:
Memory is not enabled: Copilot token is required.shortly after startup~/.cache/copilot/copilot-user-cache.jsonwhoseretrievedAtmatches the moment auth resolves; warm launches reuse the cached entrySo the provider-attribution
model.list()call only loses the race when the Copilot user info has to be fetched over the network. Themodel-provider-labelseffect re-runs when the model catalog loads, so the labels do populate afterwards and the error is cosmetic. Gating the first call on auth readiness, or not surfacing a pre-auth failure as asession.error(as with #3596), would avoid it.versegeek commentedon Oct 1, 2026
@kenneth-burgener-sndk Thanks for the detailed investigation and the warm/cold startup comparison!
Your findings support the startup authentication race I suspected. It's helpful to know this also occurs on Linux with stored credentials, not just on macOS with
COPILOT_GITHUB_TOKEN, so the issue doesn't appear to be specific to environment-variable authentication.Waiting for authentication to be ready before the initial
model.list()call sounds like a reasonable fix. Thanks again for adding these data points!Tak2121 commentedon Oct 1, 2026
copilot-cli-bot commentedon Oct 4, 2026
This appears to be resolved as of GitHub Copilot CLI v1.0.91. Please update to that release or a newer stable version. We're closing this as completed. If it still happens, please comment with your version and reproduction steps.