coleam00/Archon · error

Provider '${providerId}' does not support subscription login

Error message

Provider '${providerId}' does not support subscription login.

What it means

Thrown by startOAuth in packages/core/src/credentials/oauth-bridge.ts:245 when the requested provider id is not in SUBSCRIPTION_PROVIDERS, the single source of truth for which vendors can be connected via subscription (OAuth) login. This is the deep gate inside the bridge, beyond the route/CLI check, so the bridge can never be driven past it. It means the provider must use an API-key credential instead.

Source

Thrown at packages/core/src/credentials/oauth-bridge.ts:245

}

/**
 * Begin a subscription login for a vendor (anthropic/openai/github-copilot;
 * legacy claude/codex/copilot ids accepted). Kicks off the held login —
 * Pi's `login()` for anthropic/github-copilot, the Archon-owned PKCE flow for
 * openai — and returns once the first signal has populated the URL (manual)
 * or user-code (device), or a short timeout elapses.
 */
export async function startOAuth(userId: string, providerId: string): Promise<StartOAuthResult> {
  // Expired sessions may also hold a callback server — include them in the
  // settle-wait below so the port is free before the new login binds it.
  const supersededSettled: Promise<void>[] = sweepExpired();
  const provider = normalizeCredentialVendor(providerId);
  // SUBSCRIPTION_PROVIDERS is the single source of truth for "connectable via
  // subscription". Gate here too so the bridge can't be driven past the
  // route/CLI check.
  if (!SUBSCRIPTION_PROVIDERS.has(provider)) {
    throw new Error(`Provider '${providerId}' does not support subscription login.`);
  }
  // `openai` (ChatGPT/Codex) runs the Archon-OWNED PKCE flow (openai-oauth.ts)
  // instead of Pi's: Pi drops the id_token the Codex CLI requires (#1924), and
  // Pi's flow would also bind a local fixed-port callback server — the #1963
  // wedge pattern this bridge just escaped. piProvider stays undefined for it.
  const piProvider =
    provider === OPENAI_SUBSCRIPTION_VENDOR ? undefined : piOAuthProviderFor(provider);
  if (provider !== OPENAI_SUBSCRIPTION_VENDOR && !piProvider) {
    throw new Error(`Provider '${providerId}' does not support subscription login.`);
  }
  // Hard-cancel prior in-flight logins that would collide with this one:
  //   - same user (one login per user — the original I3 behavior), and
  //   - same vendor when the flow binds a local fixed-port callback server
  //     (anthropic: 53692). Two such logins can't coexist in one process, and
  //     an abandoned one would otherwise EADDRINUSE every later start for ANY
  //     user until restart (#1963). The newest interactive request wins; a
  //     superseded session's user sees "session not found" on their next poll
  //     and can simply restart — recoverable, so the heuristic is acceptable.

View on GitHub (pinned to 0773b97458)

Solutions

  1. Use one of the supported subscription provider ids: anthropic (or legacy claude), openai/codex, github-copilot (or copilot).
  2. Check spelling/casing of the provider id before calling startOAuth.
  3. If the provider only supports API keys, configure it via the API-key credential path instead of subscription login.
  4. If you are adding a new vendor, add it to SUBSCRIPTION_PROVIDERS (and provide piOAuthProviderFor or an owned flow) before routing to startOAuth.

Example fix

// before
await startOAuth(userId, 'claude-code');
// after
await startOAuth(userId, 'anthropic');
Defensive patterns

Strategy: validation

Validate before calling

import { SUBSCRIPTION_PROVIDERS, normalizeCredentialVendor } from '@archon/core/credentials';
if (!SUBSCRIPTION_PROVIDERS.has(normalizeCredentialVendor(providerId))) {
  throw new Error(`Provider '${providerId}' is not connectable via subscription login.`);
}
await startOAuth(userId, providerId);

Prevention

When it happens

Trigger: Calling startOAuth(userId, providerId) with a provider id that normalizes to a vendor outside SUBSCRIPTION_PROVIDERS (e.g. 'openai' API-key-only configs, unknown/misspelled ids like 'anthropicai', or an API-key provider such as a plain OpenAI key vendor).

Common situations: Typo in the provider id in a CLI command or HTTP route call; passing a raw display name or alias that normalizeCredentialVendor maps to a non-subscription vendor; calling the bridge directly in a test or script for a vendor that only supports API keys; version drift where a new vendor was added to routes but not to SUBSCRIPTION_PROVIDERS.

Related errors


AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/e76a6eaa050d4835. Report an issue: GitHub.