Repository navigation
Startup error "Failed to read model provider attribution: Error: Not authenticated" in 1.0.89 #5008
Description
Activity
- سلام نمیتونم استفاده کنم ولی از پلیس فتا دارم پیگیری میکنم ممنونم در تاریخ چهارشنبه ۳۰ سپتامبر ۲۰۲۶، ۰۶:۴۱ Geek ***@***.***> نوشت:…*versegeek* created an issue (github/copilot-cli#5008) <#5008> 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 1. Authenticate via the COPILOT_GITHUB_TOKEN environment variable (OAuth token; no accounts stored via /login). 2. Start copilot in a trusted directory. 3. 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_TOKEN environment 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. — Reply to this email directly, view it on GitHub <#5008?email_source=notifications&email_token=BMBZYCUNXM3DAM6BW4NVA7D5RR2W5A5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJWGQYDENZZGU3TDJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMBZYCV5JLACT4SHNKOMHCL5RR2W5AVCNFSNUABFKJSXA33TNF2G64TZHM2TQNJYGYYDMNRUHNEXG43VMU5TKNRUGAZDOOJVG4Y2C5QC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
yup need fix
Having the same issue but with windows os
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:Startup Auth ready after Launches model-provider-labelserrorWarm ~1-2 ms 8 0 of 8 Cold ~530-615 ms 3 2 of 2 with a surviving session log (each logged twice, ~170-195 ms after session.start)Cold launches:
- were the first launch after a long idle period (12 h+ here); launches within minutes of a previous one were warm
- log
Memory is not enabled: Copilot token is required.shortly after startup - write a new entry to
~/.cache/copilot/copilot-user-cache.jsonwhoseretrievedAtmatches the moment auth resolves; warm launches reuse the cached entry
So 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.Reacted by Geek and ChristianAdditional 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:Startup Auth ready after Launches
model-provider-labelserror
Warm ~1-2 ms 8 0 of 8
Cold ~530-615 ms 3 2 of 2 with a surviving session log (each logged twice, ~170-195 ms aftersession.start)
Cold launches:- were the first launch after a long idle period (12 h+ here); launches within minutes of a previous one were warm
- log
Memory is not enabled: Copilot token is required.shortly after startup - write a new entry to
~/.cache/copilot/copilot-user-cache.jsonwhoseretrievedAtmatches the moment auth resolves; warm launches reuse the cached entry
So 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.@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!- زمانی که رفتم پلیس فتا زه همتون نوشتن میدم آدم ازیت کردن یعنی چی در تاریخ چهارشنبه ۳۰ سپتامبر ۲۰۲۶، ۱۹:۵۷ Kenneth Burgener < ***@***.***> نوشت:…*kenneth-burgener-sndk* left a comment (github/copilot-cli#5008) <#5008 (comment)> 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 CLI to the first authenticated-account log line ([managedSettings] self-fetch starting for account https://github.com/...) was bimodal: Startup Auth ready after Launches model-provider-labels error Warm ~1-2 ms 8 0 of 8 Cold ~530-615 ms 3 2 of 2 with a surviving session log (each logged twice, ~170-195 ms after session.start) Cold launches: - were the first launch after a long idle period (12 h+ here); launches within minutes of a previous one were warm - log Memory is not enabled: Copilot token is required. shortly after startup - write a new entry to ~/.cache/copilot/copilot-user-cache.json whose retrievedAt matches the moment auth resolves; warm launches reuse the cached entry So the provider-attribution model.list() call only loses the race when the Copilot user info has to be fetched over the network. The model-provider-labels effect 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 a session.error (as with #3596 <#3596>), would avoid it. — Reply to this email directly, view it on GitHub <#5008?email_source=notifications&email_token=BMBZYCQZDEZLMOKLHWQ2RP35RUX6LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJRGUZTKOBSGY32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5915358267>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMBZYCXOZ5OUJ4P3NK7ERMD5RUX6LAVCNFSNUABFKJSXA33TNF2G64TZHM2TQNJYGYYDMNRUHNEXG43VMU5TKNRUGAZDOOJVG4Y2C5QC> . You are receiving this because you commented.Message ID: ***@***.***>
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.
Describe the bug
Since 1.0.89, every new interactive session shows this error twice right after startup:
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-pickerandmodel-provider-labels) callsmodel.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
COPILOT_GITHUB_TOKENenvironment variable (OAuth token; no accounts stored via/login).copilotin a trusted directory.Timing from session events and the process log (relative to
session.start):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
COPILOT_GITHUB_TOKENenvironment variable