Surface invite-only/account-not-enabled auth blockers in JSON status

[pejmanjohn]

What happened

Ada ran:

npx --yes @stripe/link-cli auth login --client-name "Ada OpenClaw on Mac mini" --format json

The CLI successfully returned a device setup URL + phrase. She then started polling:

npx --yes @stripe/link-cli auth status --interval 5 --max-attempts 60 --format json

From the CLI/agent side, the status stayed effectively:

{
  "authenticated": false,
  "pending": true
}

Eventually it timed out / remained unauthenticated.

On my phone, though, the Link UI showed the real blocker:

Thanks for your interest
This feature is currently invite-only.

My email was expected to be whitelisted, but apparently wasn’t enabled yet.

Why this matters for agents

The agent saw “still pending” for several minutes, but I saw “invite-only.” That split-brain makes it hard for the agent to give the user a helpful next step. In a chat interface, Ada could only say “auth didn’t complete,” not “your account isn’t enabled for Link agents yet.”

Suggested improvement

If the device authorization flow can expose this state, it would be very helpful for auth status --format json to return a structured blocker, e.g.

{
  "authenticated": false,
  "status": "blocked",
  "reason": "invite_only",
  "message": "This Link account is not enabled for agent payments."
}

Even a terminal final state like authorization_blocked / access_not_enabled would be much better than silent pending until timeout.

Demo/UX impact

This is a small thing, but it matters a lot when the CLI is being driven by an assistant. The agent needs to know whether it should keep polling, ask the user to approve, or tell the user they need access enabled.

Thanks — the underlying product shape is very promising. This was the first rough edge we hit while testing it from OpenClaw.

[stevekaliski-stripe]

This is being resolved shortly!