Support ChatGPT-subscription auth for Codex behind custom base_url / self-hosted observability gateways

What feature would you like?

Support ChatGPT-subscription authentication when Codex is pointed at a custom base_url (self-hosted observability gateways/proxies).

Current behavior

With codex login via ChatGPT (plan auth) and a custom provider base_url targeting a local transparent proxy (tested: MLflow AI Gateway 3.14.0, which forwards the client's own credentials unchanged), requests reach api.openai.com/v1/responses and fail:

401 {"detail":"You have insufficient permissions for this operation. Missing scopes: api.responses.write. ..."}

Codex CLI 0.144.3; codex login status → "Logged in using ChatGPT"; compression disabled (--disable enable_request_compression) to rule out transport issues — the request and credential forwarding are otherwise clean.

This matches the documented auth split (https://developers.openai.com/codex/auth/): plan-authenticated Codex uses a separate service path, and the plain API accepts only API keys. The consequence: routing Codex through a local tracing proxy requires switching to API-key auth and per-token billing, even though the traffic is still the official client, the same models, and the same subscriber.

Why it matters

Observability gateways in front of coding agents (session traces, token counts, budgets, guardrails) are increasingly standard — e.g. MLflow's Coding Agents integration, LiteLLM, and similar self-hosted proxies. Today those setups work subscription-native for some agent CLIs but not Codex-on-ChatGPT, which either silently pushes users to API billing or produces the misleading scopes error above. (MLflow's docs handle it honestly — "you need to authenticate with your API key instead of ChatGPT subscription" — but the capability gap is on the auth side, so filing here.)

Desired outcome (any of)

1. Plan tokens accepted on the Responses API for requests originating from official Codex clients, regardless of an intermediate proxy; or
2. A documented, supported pattern for subscription-authenticated Codex behind a user-controlled gateway (even localhost-only); or
3. An explicit statement that this is unsupported, so gateway integrations can document it and fail with a clear error.