Codex sign-in parity: expose + explain ChatGPT-subscription vs OpenAI-API-key, the way Claude already does

[serge-ivo]

Problem

The engine editor (agents/coder/web/src/EnginesModal.tsx) makes Claude's billing crystal clear — Auto / Machine login / Subscription token (Claude Code key) / Anthropic API key (per-token billing), with continuity/metering/attribution notes. But the subscription option is hardcoded Claude-only:

• UI: {isClaude && <option value="subscription">…}
• resolveEngineEnv (workers/api/src/lib/coding-engines.ts): if (session.clientType !== "claude") return … machine login — "Only Claude has a subscription token env; for other engines these modes mean the machine login."

So for Codex the user only gets Auto (this machine's login), Machine login only, and OpenAI API key (per-token billing). That's wrong: Codex supports Sign in with ChatGPT (codex login, a Plus/Pro/Team plan — no API key, no per-token charge), the direct analogue of Claude's subscription. Today a ChatGPT subscriber is forced into either:

• "Machine login" — which the platform itself records as unattributed spend (it can't tell whether the machine's stored Codex login is a ChatGPT subscription or an API key — this is the A Codex coding session is completely invisible — unmetered like a tmux drive, but unlike a tmux drive the absence is never recorded, and classifyEngineMetering has zero production callers #556 / 99.62% of the account's AI value is "Payer not established" — one stored claude-code token would resolve it, and nothing on any surface says so #551 ambiguity), or
• "OpenAI API key (per-token billing)" — per-token charges they may not want.

The single distinction the product exists to make clear — API key vs subscription — is exactly the one missing for Codex.

Mechanic (why it's implementable, and how it differs from Claude)

Claude injects a token: resolveEngineEnv sets CLAUDE_CODE_OAUTH_TOKEN and strips ANTHROPIC_API_KEY. Codex has no injectable subscription token — its ChatGPT auth lives in ~/.codex/auth.json on the runner from codex login. So for Codex, "subscription" is the mirror image minus the injection:

• Codex subscription mode = strip OPENAI_API_KEY (empty-value-means-remove, already supported by the runner's mergeEnv) so the CLI falls back to its own codex login ChatGPT session instead of an inherited/vault key. This is the same move Claude's subscription mode makes to stop an inherited key from silently forcing per-token billing.
• api-key mode stays as-is (inject OPENAI_API_KEY from the vault, per-token).

Proposed fix

1. Generalize EngineAuth beyond Claude. Let subscription apply to Codex; resolveEngineEnv for Codex-subscription strips the provider key (uses codex login). Keep the type the same (auto | machine | subscription | api-key); just stop gating subscription on clientType === "claude".
2. Per-engine copy that names the real mechanism (no generic labels):
   • Claude subscription → "Subscription token (from claude setup-token)"
   • Codex subscription → "ChatGPT subscription (from codex login) — no per-token charge, draws your ChatGPT plan"
   • api-key (either) → "{Anthropic|OpenAI} API key — billed per token to your own account"
   • machine → say concretely what that login IS per engine (claude.ai keychain session / codex login / OpenAI key configured in the CLI) and that its spend is unattributable.
   • auto for Codex → "ChatGPT login if present, else whatever the CLI has" instead of the current bare "this machine's login".
3. Attribution note (engine-attribution-note) covers Codex, mirroring the Claude hasClaudeCodeToken logic: read whether a usable Codex login is present and state the payer outcome (subscription = drawn from plan, unattributed at token level but not per-token-billed vs api-key = per-token to OpenAI).
4. Symmetric "what this costs" line shown for both engines so API-key-vs-subscription is legible at a glance, not inferred from an option label.

Acceptance

• Codex presets offer a "ChatGPT subscription" sign-in option; selecting it makes the runner spawn Codex with OPENAI_API_KEY stripped (verify via the engine-auth report: resolved != api-key).
• Each engine's sign-in options and notes name the concrete credential (claude setup-token / codex login / provider API key) and its billing consequence in plain words.
• engineAuthReport/engineAuthWarning produce correct asked-vs-got warnings for Codex (e.g. "you chose ChatGPT subscription but an OpenAI key reached the engine → billing per token").
• Existing Claude behaviour is unchanged (regression-pinned).

Refs: #551, #556, #731 (invocation mode is the sibling per-preset dimension), #728

[serge-ivo]

Review corrections (adversarial BA assessment, 2026-08-22)

The gap is real and the issue should ship, but the core mechanic is not as reliable as written, and the clarity promise has holes:

1. Stripping OPENAI_API_KEY may NOT reliably route to codex login — verify before trusting it. Upstream reports the precedence is inverted/version-dependent: with an active ChatGPT login, an OPENAI_API_KEY may be ignored anyway (openai/codex#2733), and an expired codex login silently swaps in a "dummy" key (#37192) — the exact silent-billing failure this issue exists to remove. Add to acceptance: on a machine with BOTH codex login active and OPENAI_API_KEY in the shell, prove that subscription mode demonstrably bills the ChatGPT plan (via the engine-auth report resolving to not-api-key), on a recorded codex-cli version.

2. Add a codex login presence check, mirroring hasClaudeCodeToken. The Claude attribution note already changes live based on whether the vault token exists (EnginesModal.tsx). Codex-subscription needs the equivalent: detect whether a usable codex login is present, and show a pre-save warning when the user picks subscription but no codex login is detectable ("you chose ChatGPT subscription, but codex login hasn't been run on this machine — the engine will fall back to machine credentials or fail to start"). Decide in-issue: a runner-side login-status probe (heavier) vs an honest "check manually" note.

3. Disambiguate subscription vs machine-login for Codex. They behave identically unless an OPENAI_API_KEY is also present (subscription strips it). The attribution copy must say so: "If you also have an OpenAI API key saved, this mode prevents it from being used — Codex runs on your ChatGPT plan instead." Otherwise a user with both won't understand why the choice exists.

4. Don't let the metering note dead-end Codex. Today it says "spend is not measured — not free, it is invisible" and offers a Claude-only remedy. For Codex-subscription, either (a) honestly state "Codex spend isn't visible on the Usage page regardless of sign-in (no per-token breakdown emitted in raw mode)", or (b) sequence this after First-class Codex engine via codex exec --json (structured), not raw stdout capture #729 so metering becomes real. Pick one explicitly.

Refs: upstream openai/codex#2733, #37192; #551 (the Claude sibling of this payer-visibility gap), #729.