[Bug]: Grok provider always shows "authentication could not be verified" even when the health check fully succeeds

[Swayam2004]

What happened?

The Grok provider works: models list, sessions run, grok --version and the ACP handshake both succeed. But every health-check cycle ends with the status detail:

Installed and ready, but authentication could not be verified.

This reads as an auth failure. It is not one. The check never verifies auth at all, and the UI phrases "unknown" as a warning.

Environment

OS: Linux x86_64
T3 Code: 0.0.33 alpha (AppImage)
Grok CLI: grok 1.0.5 (5115b46bc9)
binaryPath: absolute path to ~/.grok/downloads/grok-linux-x86_64
Health check interval: default (300 s)

Grok CLI is authenticated and works standalone.

Evidence

Local provider cache after a successful cycle (~/.t3/caches/grok.json):

{
  "installed": true,
  "version": "1.0.5",
  "status": "ready",
  "auth": { "status": "unknown" },
  "models": [{ "slug": "grok-4.6" }, { "slug": "grok-4.5" }, { "slug": "grok-build" }]
}

ready plus models, but auth stuck on unknown. The server trace agrees: checkGrokProviderStatus spans complete in ~6.1-6.6 s with a Success exit (version probe plus ACP session startup).

Root cause

Two pieces of source line up:

1. checkGrokProviderStatus never derives an auth result. Every success path returns auth.status: "unknown" (apps/server/src/provider/Layers/GrokProvider.ts:305-310). Unlike Codex, which gets auth from its account/read response, or Claude, which gets it from SDK initialization, Grok's ACP session is used only for model listing.
2. The web client renders any ready snapshot with unknown auth using that message as fallback detail (apps/web/src/components/settings/providerStatus.ts:77-80, from feat: Multi-Provider support #2277).

So a completely healthy check displays a scary auth warning every five minutes.

Expected behavior

Either the check verifies authentication (the ACP session already talks to xAI with valid OAuth, so some session response should confirm it), or a ready provider with unverified auth renders neutrally instead of sounding like a failure.

Possible directions

1. Derive auth status inside the existing ACP session, mirroring how CodexProvider uses account/read.
2. If that is not feasible short-term, change the fallback text for ready snapshots to something like "Installed and ready; authentication not checked", or drop it when status === "ready".

Related

• [Bug]: Windows Codex provider probe times out even though Codex CLI is installed and authenticated #2495: similar confusion where a probe-layer gap reports as an availability/auth problem.