Official Sign in with ChatGPT plan usage and dynamic model discovery

[hrgarber]

I built and locally verified a prototype that updates Prime Agent’s openai-codex integration to use OpenAI’s official Sign in with ChatGPT plan-usage flow.

This also addresses #3262 without maintaining a static list of account models.

What the prototype covers

• OpenAI’s documented dynamic client registration flow and plan-usage scopes/resource.
• Persistence of the issued client ID for refresh and registration isolation.
• Account-visible model discovery from GET https://api.openai.com/v1/models.
• Filtering on visibility == "list" and supported_in_api == true.
• Compiled transport pinning so remote metadata cannot redirect inference.
• Official POST https://api.openai.com/v1/responses inference with store: false.
• Account/registration-scoped last-good model caching.
• Model-picker and RLM exposure of dynamically discovered models.

No new dependency is required.

Local verification

Using a ChatGPT subscription account, I verified:

• browser login completed and credentials persisted;
• forced expiry refreshed and rotated both OAuth tokens;
• account discovery returned current models, including gpt-6.1-terra;
• prime-agent model list terra showed the dynamically discovered models;
• live inference through the official Responses API returned the expected response using gpt-6.1-terra; and
• the optimized installed build repeated the discovery and inference proof through the normal prime-agent command.

Credential values, account identifiers, and local paths are not present in the implementation or fixtures.

Design question before a pull request

The existing provider also exposes WebSocket/WebSocket-cached transport settings and custom base URLs from its older ChatGPT backend integration. OpenAI’s SIWC documentation explicitly directs plan usage to the public Responses endpoint and away from ChatGPT backend-api, but does not establish SIWC support for those compatibility surfaces.

Before preparing a PR, I would appreciate maintainer direction on the intended boundary:

1. Should SIWC plan usage be a clean official-HTTP-only path while legacy transport behavior remains separately available?
2. Or should the current openai-codex provider migrate entirely to the official path, with the old transport settings removed/deprecated?
3. Should custom proxies remain supported for this provider even though the authenticated plan-usage endpoint is fixed by the SIWC contract?

I read CONTRIBUTING.md and understand that unsolicited pull requests are automatically closed. Would a maintainer be interested in reviewing this approach and inviting a focused pull request once that compatibility boundary is agreed? I can provide the implementation, focused tests, complete sanitized validation results, ownership classification, and parity evidence.

---

Update after independent review: I found OAuth-validation gaps in the prototype before preparing any PR, so I rolled back the local installation and am treating the prototype as not ready. The next revision will require cryptographic ID-token verification (signature, issuer, audience, expiry, and nonce), granted-scope validation, sanitized token errors, and explicit OAuth-error callback handling, with negative regression tests. I will not submit or recommend the implementation until those checks pass.