feat(openai): add ChatGPT OAuth-backed ChatOpenAICodex chat model

[open-swe]

Docs

Adds a new ChatOpenAICodex chat model and a small chatgpt_oauth module so users can authenticate with their ChatGPT subscription (OAuth 2.0 Authorization Code Flow with PKCE) and route Responses-API requests to the ChatGPT Codex backend at https://chatgpt.com/backend-api/codex. Login and token persistence live behind a refresh-aware ChatGPTOAuthTokenProvider protocol so they stay decoupled from model invocation. The existing API-key ChatOpenAI behavior is untouched. By default the file-backed provider writes to ~/.langchain/chatgpt-auth.json to avoid stomping on Codex CLI / VS Code sessions at ~/.codex/auth.json. No new required dependencies are introduced (uses stdlib + httpx).

from langchain_openai import ChatOpenAICodex
from langchain_openai.chatgpt_oauth import login_chatgpt

login_chatgpt()
model = ChatOpenAICodex(model="gpt-5.5")
response = model.invoke("hello")

Opened collaboratively by Mason Daugherty and open-swe.

[corridor-security]

Security Issues

• OAuth Token Exfiltration via Caller-Controlled base_url
ChatOpenAICodex uses a ChatGPT OAuth access token as the OpenAI SDK api_key, but the constructor's setdefault logic preserves any caller-supplied base_url / openai_api_base — it only fills in the Codex URL when neither field is already set. If an attacker can influence model configuration (e.g., via a serialized config, environment-driven instantiation, or a multi-tenant service that passes user-supplied kwargs to ChatOpenAICodex), they can point the model at an arbitrary HTTPS endpoint. The OpenAI SDK will then send the victim service's Authorization: Bearer <access_token> and ChatGPT-Account-Id headers to the attacker-controlled host on every invocation.

Recommendations

• Enforce that base_url / openai_api_base matches exactly CHATGPT_CODEX_BASE_URL inside _apply_codex_defaults, or unconditionally overwrite both fields with the constant before wiring in the OAuth token provider.