Support ChatGPT Plus/Pro OAuth as a login provider

[qipenglin]

Problem

Kimi Code currently supports first-party Kimi OAuth and API-key based third-party providers. Users with an active ChatGPT Plus/Pro subscription cannot use that subscription from Kimi Code without manually configuring an API-key provider, which is a different billing/auth path from ChatGPT subscription access.

There is interest in adding a /login option for ChatGPT Plus/Pro OAuth that authorizes through OpenAI/ChatGPT and uses the Codex-compatible ChatGPT backend for model requests.

Proposed behavior

Add an optional ChatGPT Plus/Pro OAuth provider to /login:

• show OpenAI ChatGPT Plus/Pro (OAuth) in the login platform selector
• authorize via OpenAI device-code OAuth
• store and refresh OAuth credentials in Kimi Code's existing credentials storage
• create an openai-codex provider in config.toml
• fetch the available Codex model catalog from the ChatGPT/Codex backend after login, then fall back to a conservative built-in model list if catalog fetching fails
• inject per-request ChatGPT account headers derived from the OAuth JWT
• avoid sending request parameters rejected by the ChatGPT Codex backend, such as max_output_tokens

Notes and risks

This likely needs to be treated as experimental because the ChatGPT Codex backend and model catalog endpoint are not a stable public API surface. In local exploration, model availability and context windows were returned by the backend and could vary by client-version gate and account entitlement. For example, one account catalog exposed gpt-5.5, gpt-5.4, and gpt-5.4-mini, while gpt-5.3-codex-spark was rejected for ChatGPT-account use.

A good first implementation should therefore:

• gate the provider behind an experimental flag if maintainers prefer that for non-public upstream APIs
• use server-returned model metadata when available rather than hardcoding the list
• keep a fallback model list for offline/catalog failure cases
• include tests for token refresh, account-id extraction, catalog parsing, provider config generation, and avoiding unsupported request parameters
• document that this login path uses a ChatGPT subscription rather than an OpenAI API key

Prior art

Similar ChatGPT/Codex OAuth integrations exist in other agent CLIs such as opencode and pi, using OpenAI OAuth credentials with the ChatGPT Codex backend.

Open questions

• Should this provider be hidden behind KIMI_CODE_EXPERIMENTAL_* initially?
• What client_version strategy should Kimi Code use when fetching the ChatGPT Codex model catalog?
• Should /provider display OAuth-backed providers, or should they remain managed only through /login and /logout like Kimi Code OAuth accounts?