[benbrandt]

Adds schema support for the get-auth-state RFD behind a new unstable_auth_status feature (included in unstable), in both v1 and v2 with the same wire shape. It also revises the RFD.

Shape

// auth/status response and auth/status_update notification
{
  state: "authenticated" | "unauthenticated" | "not_required" | "unknown" | string
  accounts?: AuthAccount[]
  _meta?
}
AuthAccount { label: string, active?: boolean, name?, email?, organization?, _meta? }

• state is required and strict, and it's the only field clients act on. Clients treat values they don't recognize as unknown. not_required covers local models. Expired or invalid credentials are reported as unauthenticated.
• accounts is display-only and lenient: malformed values are ignored and malformed entries are skipped, following the same pattern as authMethods. API keys show up as label-only entries. Several accounts can be active, for example one per provider. Clients must not use these fields as stable identifiers and should not log them or send them to telemetry.
• auth/status_update is a connection-scoped agent→client notification that carries the full snapshot. Agents send it when the status changes, including when the user signs in or out outside the client.
• Capability: agentCapabilities.auth.status: {}. It's an object rather than the RFD's original boolean, to match logout, fork and providers.

RFD changes

The original RFD had { authenticated: bool, message?: string }. The revised shape comes from a survey of ACP registry agents, the Claude and Codex adapters, Junie, and prior art like VS Code accounts, gh auth status, gcloud and az:

• About half the agents hold credentials for several providers, which is why accounts is a list.
• A boolean can't express "no auth needed" or "can't tell", which is why state has four values.
• Credential kinds, plans and credential sources differ too much between agents to standardize, so they're left to label and _meta.

How this interacts with the providers API is left open while that API is reworked.

I also replaced the outdated setLlmEndpoints references in the RFD.

Docs

• v2 overview: a row in the unstable features table.
• Initialization pages: auth.status on the v2 page and status on the v1 page.
• RFD: agents MUST NOT reject auth/status with auth_required, since auth/status is how a Client finds out that authentication is required.

The authentication pages themselves don't describe the feature yet, so the RFD is the reference for now, as the overview table says.