Grok provider health check times out because it starts a full ACP session (and every MCP server)

[troybrave]

Summary

T3 Code marks Grok as broken (Grok CLI is installed but ACP startup timed out after 15000ms) even when Grok CLI is healthy and Grok chats already work.

This is not a missing install. The Grok status probe starts a full ACP session (initialize → authenticate → session/new) with a 15s deadline. session/new boots every configured MCP server for the current cwd. On a real workspace that is enough to miss 15s, and the error snapshot is then persisted to ~/.t3/caches/grok.json.

Environment

• T3 Code Alpha (desktop), macOS
• Grok CLI 1.0.5 (/Users/<user>/.grok/bin/grok)
• Authenticated (grok models prints You are logged in with grok.com.)
• Open workspace with 13 MCP servers (Linear, Airtable, Notion, Figma, …)

Reproduction

1. Install and log in to Grok CLI.
2. Open a workspace whose Grok/T3 MCP list is non-trivial (more than a couple of servers).
3. Enable the Grok provider (or let T3 run the background provider check).
4. Observe provider status: error / Grok CLI is installed but ACP startup timed out after 15000ms.
5. Meanwhile, an actual Grok thread in T3 continues to work.

Expected

A background health check should not start a full agent session.

If grok --version and grok models succeed, Grok is installed and authenticated. Model discovery should use that CLI path (or initialize-only ACP), not session/new.

A probe timeout must not persist status: "error" over a working provider (see also #7232).

Actual

checkGrokProviderStatus in apps/server/src/provider/Layers/GrokProvider.ts:

• grok --version (4s bound)
• then discoverGrokModelsViaAcp → makeGrokAcpRuntime → acp.start() which does initialize + authenticate + session/new
• cwd: process.cwd() (the T3 backend / workspace)
• GROK_ACP_MODEL_DISCOVERY_TIMEOUT_MS = 15_000
• timeout branch writes status: "error" and caches it

Grok CLI still loads MCP servers from user/workspace config even when T3 sends mcpServers: [].

Evidence (this machine)

Direct ACP handshake matching T3’s sequence (initialize + authenticate cached_token + session/new) completes in ~2.2s from a throwaway cwd.

grok inspect --json in the workspace reports 13 mcpServers.

The failing T3 probe at 2026-08-21T00:57:31.511Z spawned Grok pid that reached authenticate / model catalog (~4–9s) and never created a session before the 15s cap. ~/.t3/caches/grok.json stayed status: "error" with auth.status: "unknown" while a live T3 Grok thread on grok-4.6 kept running.

checkedAt is captured at the start of checkGrokProviderStatus, so the cache timestamp looks like the check finished instantly.

Related

• [Bug]: Grok provider ACP startup times out on Linux when Grok emits unsolicited skills-reload JSON-RPC responses #3666 — same 15s message; Linux skills-reload string JSON-RPC ids
• [Bug]: Grok provider: skills/slash commands empty; ACP crash on skills-reload (BigInt RequestId) #4109 — skills-reload BigInt RequestId crash during checkGrokProviderStatus
• Grok provider check can open browser login without user action #5852 — background probe can open a browser login
• [Bug]: Grok provider always reports auth "unknown" ("authentication could not be verified") even after its own ACP authenticate succeeds #7505 — success path still hard-codes auth: { status: "unknown" }
• fix(server): a provider probe timeout no longer marks the provider broken #7232 — timeout should not mark the provider broken (open)

Suggested fix (small)

1. Discover models with grok models (already prints default + available models, and login state). Do not spawn grok agent stdio for a health check.
2. If a lightweight ACP check is still wanted, do initialize only — never session/new.
3. On probe timeout after a successful --version, keep last known ready status (or warning), do not persist error.
4. Set auth.status from grok models / authenticate result (#7505).

I can open a tightly scoped PR for (1)+(3) if wanted.

[troybrave]

Fix in #7747 — health check now uses grok models instead of spawning a full ACP session.