check reports ready: true and verified: true when the Grok CLI is not authenticated

[dayelostraco]

Summary

grok-bridge.mjs check reports ready: true, auth.loggedIn: true, and auth.verified: true while the Grok CLI is logged out. The readiness gate passes, so a delegate run fails later at the first real API call instead of at the check that exists to prevent exactly that.

Environment: plugin v0.2.1 (commit 92b76a6), grok CLI 1.0.3 (1a29d5bc12d4), Node v25.5.0, macOS 15 (arm64).

Reproduction

With the Grok CLI installed but not logged in:

$ grok models
You are not authenticated.

Default model: grok-4.5

Available models:
  * grok-4.5 (default)

$ grok models >/dev/null 2>&1; echo $?
0

$ node scripts/grok-bridge.mjs check --json
{
  "ready": true,
  "grok": { "available": true, "detail": "grok 1.0.3 (1a29d5bc12d4)" },
  "auth": {
    "available": true,
    "loggedIn": true,
    "detail": "You are not authenticated.",
    "source": "models-probe",
    "authMethod": "grok-cli",
    "verified": true
  },
  "nextSteps": []
}

The detail field carries the correct answer. Every field that consumes it is wrong.

Root cause

Two independent defects compound.

1. The verdict ignores its own evidence. scripts/lib/grok.mjs:108-119, on the result.status === 0 path:

const loggedInHint = /logged in|available models|default model/i.test(stdout);
return buildAuthStatus({
  available: true,
  loggedIn: true,      // hardcoded
  detail: loggedInHint
    ? firstLine(stdout) || "grok models succeeded"
    : firstLine(stdout) || "grok models succeeded (treated as logged in)",
  source: "models-probe",
  authMethod: "grok-cli",
  verified: true       // hardcoded
});

loggedInHint is computed and then used only to choose the wording of detail. It never reaches loggedIn or verified, which are literals. Exit status 0 alone determines the verdict.

2. The hint would false-positive anyway. Even if loggedInHint gated the verdict, the unauthenticated output contains both Default model: and Available models:, so the regex matches in exactly the state it needs to reject.

The underlying premise is stated in scripts/grok-bridge.mjs:190: "Verify with grok models — a successful run means you are logged in." That does not hold for grok CLI 1.0.3, which exits 0 in both states.

Suggested fix

Since the CLI's exit status does not distinguish the two states, the probe has to read the output. A negative assertion is safer than a positive one here, because the authenticated banner may be reworded over time while the failure string is the thing actually being detected:

const notAuthed = /not authenticated|not logged in|please log in/i.test(stdout);
const loggedIn = !notAuthed && /you are logged in/i.test(stdout);
return buildAuthStatus({
  available: true,
  loggedIn,
  detail: firstLine(stdout) || "grok models succeeded",
  source: "models-probe",
  authMethod: loggedIn ? "grok-cli" : null,
  verified: loggedIn
});

Worth considering as a companion change upstream in the CLI: having grok models exit non-zero when unauthenticated would let this probe stay simple, and would fix any other integration that reasonably assumes exit 0 means success.

Additional signal

The advertised model roster also differs by auth state, which is a second reason not to trust unauthenticated output. Logged out reports grok-4.5 as default; logged in reports grok-4.6. So the probe is reading a stale roster in addition to missing the auth failure.

Impact

Low severity, high friction. check is the one command whose entire job is to answer "is this ready", and it currently answers yes on a logged-out install with nextSteps: [], suppressing the guidance at scripts/grok-bridge.mjs:188-191 that would otherwise tell the user exactly what to do.

Happy to send a PR for the grok.mjs change if that is useful.