Repository navigation
Grok provider check can open browser login without user action #5852
Description
Activity
- added a commit that references this issue
on Aug 16, 2026 Fix is in #7070 (
b0079ede). A background Grok provider check no longer starts ACP when there is noXAI_API_KEYand no~/.grok/auth.json. Settings shows unauthenticated and asks forgrok logininstead of opening a browser.Related report #4983 covers the same problem and adds useful evidence.
Both reports start Grok browser authentication during background discovery without saved credentials. The discussion explicitly identifies the same root cause.
I'm linking the report here before I close it as a duplicate during an automated pass. The source report and its attachments will remain available at #4983.
Note
🤖 Claude Fable 5.1 responding on behalf of Theo
Fixed in #9154. Thank you for the detailed report, it made this straightforward to pin down.
The health check no longer opens an ACP session. It runs
grok --version, thengrok modelsfor login state, then a single ACPinitializefor model metadata. Noauthenticate, so no surprise browser login. Nosession/new, so no MCP servers boot during a background check. Auth is now reported as authenticated or unauthenticated instead of always unknown, and a failed metadata probe degrades to a warning instead of persisting an error over a working install.Against Grok CLI 1.0.13 this returns in about a second. It will be in the next nightly.
T3 Code can open a Grok/xAI browser login window during a background provider check.
What happened:
Grok CLI is installed but ACP startup timed out after 15000ms.This was surprising because no chat was started with Grok and I did not click a Grok sign-in button. From a user's point of view, an unrelated browser window appeared on its own.
Expected behavior:
grok login.A local trace showed the browser URL was an xAI OAuth page with
referrer=grok-buildand a loopback callback. The Grok logs showed there was no~/.grok/auth.json, then auth started with a browser-based flow.