`/login` has no xAI (Grok/X subscription) option — vendored `packages/ai` predates upstream's xAI OAuth

[ethan-huo]

Edited. The original report claimed the flow was already bundled and just
needed registering. That was wrong — it came from probing node_modules
instead of what actually runs. See the correction comment below; this body is
the accurate version.

With a SuperGrok / X Premium subscription there is no way to authenticate:
/login lists xAI as API-key only, which is a separately paid plan.

Version: prime-agent 0.7.0

Where the gap is

packages/ai/src/utils/oauth/ contains only:

anthropic.ts  github-copilot.ts  openai-codex.ts  index.ts  oauth-page.ts  pkce.ts  types.ts

and packages/ai/src/providers/ has no xai.ts — xAI exists purely as a model
catalog entry with env-key auth. Those three are exactly the three that show up
in the login picker, so the picker is faithfully reflecting the vendored tree.

Upstream has it

earendil-works/pi — the repo @earendil-works/pi-ai points at in its
repository field — carries the flow at packages/ai/src/auth/oauth/xai.ts,
and its packages/ai/src/providers/xai.ts mounts it the same way Anthropic and
Codex are mounted:

auth: {
    apiKey: envApiKeyAuth("xAI API key", ["XAI_API_KEY"]),
    oauth: lazyOAuth({
        name: "xAI (Grok/X subscription)",
        loginLabel: "Sign in with SuperGrok or X Premium",
        load: loadXaiOAuth,
    }),
},

Note the directory: upstream is src/auth/oauth/, the vendored copy is
src/utils/oauth/. These are two generations of the same tree, not a one-version
lag — upstream moved to a file-per-provider layout that carries auth.oauth
inline, and the vendored copy predates it.

can1357/oh-my-pi, another pi derivative, also ships this — as a distinct
xai-oauth provider sitting alongside the API-key xai one (/login xai-oauth).

Side observation

The published package declares @earendil-works/pi-ai as a tarball whose
package.json says 0.83.0 (upstream, has the xAI flow), while the bundle
that bin actually resolves to is built from the vendored 0.7.0 tree
(no xAI flow). If that split is deliberate, ignore this part — it just made the
first version of this report wrong.

Ask

Support xAI OAuth in /login. Whether that means porting the flow into the
vendored tree's architecture or reconciling the two trees is your call — I can't
judge that from outside.

[ethan-huo]

Correction to my own report — the "it's already there, just register it" framing
above is wrong, and I'd rather flag it than have someone chase it.

My probe imported dist/core/auth-storage.js, which resolves
@earendil-works/pi-ai from node_modules. That copy is 0.83.0, comes from
github.com/earendil-works/pi (per its package.json repository field), and
does ship dist/auth/oauth/xai.js plus a providers/xai.js that mounts
oauth: lazyOAuth({ ..., load: loadXaiOAuth }).

But that copy isn't what runs. The prime-agent bin points at
dist/bundle/cli.js, which is self-contained, and the bundle has no xAI OAuth in
it at all:

• rg 'SuperGrok' dist/bundle/ → no match
• rg 'ChatGPT Plus/Pro' dist/bundle/ → matches (so the codex flow is bundled)
• xai appears in the bundle only as a model catalog entry —
  baseUrl: "https://api.x.ai/v1" with env-key auth, no auth.oauth field

That lines up with this repo's packages/ai (0.7.0), where
src/utils/oauth/ contains only anthropic.ts, github-copilot.ts and
openai-codex.ts, and src/providers/ has no xai.ts — the vendored tree
predates the per-provider-file layout that upstream 0.83.0 uses.

So the accurate version of this issue is: the vendored packages/ai is a
different generation from the @earendil-works/pi-ai version the published
package declares as a dependency, and xAI OAuth exists only in the latter.
Adding it isn't a registration call — it's either porting the flow into the
vendored tree's architecture, or reconciling the two trees.

The user-visible symptom is unchanged: with a SuperGrok / X Premium subscription
there's no way in, since the xAI entry in /login is API-key only.

Whether the dependency/bundle version split is intentional I can't tell from the
outside — if it is, disregard that half.

[ss251]

Some independently verified data points that may help whichever of #652 / #752 / #754 moves forward, plus a zero-code interim recipe for subscription users stuck on 0.7.0 today. All verified live on 2026-08-07 against a SuperGrok Heavy subscription (macOS, Grok CLI logged in, XAI_API_KEY unset).

1. The subscription token works on two rails, and both are real

Using only the session token the official Grok CLI writes to ~/.grok/auth.json (no API key anywhere):

Rail	Extra headers needed	Result
https://api.x.ai/v1/responses	none	HTTP 200, model grok-4.5
https://cli-chat-proxy.grok.com/v1/responses	grok-cli client headers (below)	HTTP 200, model grok-4.5-build

So the claim in #754's validation section — a subscription bearer completing POST /v1/responses on api.x.ai — reproduces cleanly on an independent machine/account. Note the proxy serves the CLI-tuned grok-4.5-build variant while api.x.ai serves plain grok-4.5; the choice of rail is also a choice of model variant.

On the proxy rail I additionally verified: /v1/chat/completions also returns 200; native function calling via tools: [{type:"function", ...}] emits proper parallel function_call items and accepts function_call_output round-trips (tested with a two-call parallel case and a multi-turn tool-result loop); usage reports real input_tokens/output_tokens and cached_tokens (prompt caching works). Model metadata from the CLI's models_cache.json: 500k context window, supports_reasoning_effort: true with efforts exactly low|medium|high, "api_backend": "responses".

2. This is xAI-documented behavior, not reverse engineering

The Grok CLI ships its own README at ~/.grok/README.md; the section "Using auth.json for API Access" (~line 375) explicitly documents calling https://cli-chat-proxy.grok.com/v1/chat/completions with the token from auth.json. Two bugs in that documented example, for anyone implementing against it:

• The example's curl fails as written. The proxy requires an x-grok-client-version header; omitting it returns HTTP 426 "Your Grok CLI version (none) is outdated". Working header set: the Authorization header carrying the auth.json token, plus X-XAI-Token-Auth: xai-grok-cli, x-grok-client-version: 1.0.0, x-grok-model-override: grok-4.5 (optionally x-grok-client-identifier / x-grok-client-mode).
• The auth.json key name is dynamic. The README hardcodes "https://accounts.x.ai/sign-in" as the JSON key; on current installs the key is https://auth.x.ai::<id>. Extract with jq -r 'to_entries[0].value.key' ~/.grok/auth.json rather than a hardcoded key.

3. Zero-code interim path (works on released 0.7.0 today, no merge required)

For subscription users who need this before any of the PRs land — ~/.prime/agent/models.json:

{
  "providers": {
    "grok-cli": {
      "baseUrl": "https://cli-chat-proxy.grok.com/v1",
      "api": "openai-responses",
      "apiKey": "!jq -r 'to_entries[0].value.key' \"$HOME/.grok/auth.json\"",
      "authHeader": true,
      "headers": {
        "X-XAI-Token-Auth": "xai-grok-cli",
        "x-grok-client-version": "1.0.0",
        "x-grok-client-identifier": "grok-shell",
        "x-grok-client-mode": "headless",
        "x-grok-model-override": "grok-4.5"
      },
      "compat": { "supportsStore": false, "supportsLongCacheRetention": false },
      "models": [{
        "id": "grok-4.5", "name": "Grok 4.5 (SuperGrok)", "reasoning": true,
        "input": ["text"], "contextWindow": 500000, "maxTokens": 32000,
        "cost": {"input":0,"output":0,"cacheRead":0,"cacheWrite":0},
        "thinkingLevelMap": {"off":null,"minimal":null,"low":"low","medium":"medium","high":"high","xhigh":"high"}
      }]
    }
  }
}

Verified end-to-end: a real coding task (file read, edit, shell command, verification) ran through this config with no API key. Caveats: the CLI session token expires roughly weekly, so the failure mode is a 401 until the user re-runs grok login; and this recipe deliberately only reads what the official CLI wrote — it never acquires or refreshes xAI credentials itself.

4. One honest open question for maintainers

xAI's bundled README sanctions auth.json token reuse for personal CLI use, and the device-flow client contract in the PRs is the same one the Grok CLI itself uses (and was accepted upstream in earendil-works/pi). Whether xAI is happy with third-party harnesses shipping subscription access as a built-in product feature is still a policy call rather than a technical one — may be worth a quick check with xAI before merging, so users don't end up with revoked client access down the line.

[lmist]

#1154 is another candidate implementation, taking the port-into-the-vendored-architecture path this issue's Ask allows. Data points for whoever triages:

• RFC 8628 device flow against https://auth.x.ai with the Grok CLI's public client, so /login works headless (no loopback server or fixed port).
• Registers under the existing xai provider id and uses the OAuth registry's modifyModels hook to serve xAI models over /v1/responses only while subscription credentials are the active auth source. No models.generated.ts or KnownProvider changes; XAI_API_KEY users keep the untouched Chat Completions catalog, consistent with the two-rail findings posted above.
• Live-validated end to end on a SuperGrok subscription running the branch: device login through /login, multi-turn and tool-calling Grok 4.5 turns over api.x.ai/v1/responses, and refresh-token rotation. One relevant probe result: the live API rejects reasoning.effort: "none" (HTTP 400), so the responses rail needs the off/minimal thinking levels mapped away.
• The Codex review loop on the PR surfaced four latent auth-precedence/lifecycle gaps in the shared OAuth infrastructure (runtime --api-key vs stored OAuth in modifyModels, stale-credential env fallback, swallowed refresh errors losing actionable guidance, live sessions keeping pre-auth model objects after /login//logout); those are fixed there with regression tests and apply to any implementation of this issue.