Is there a documented auth contract for third-party clients using a ChatGPT subscription with the Responses API?

What I'm asking for

Is there — or could there be — a documented way for a third-party program to use a ChatGPT subscription credential against the Responses API, the way Anthropic documents anthropic-beta: oauth-2025-04-20 for Claude Code sessions?

Not asking for a new capability. Asking whether the existing one has a supported contract, or is CLI-internal by design.

Why it comes up

I maintain an open-source evaluation harness (Apache-2.0) that scores language models on a structured slot-filling task. It needs a plain "prompt in, tool call out" endpoint — the model's own tools and system prompt, not an agent loop — so codex exec and the Codex SDK aren't the right shape. What I want is a model endpoint.

For Anthropic that's straightforward and documented. The Vercel AI SDK's @ai-sdk/anthropic provider is pointed at the normal API host, and the CLI's stored OAuth token is sent as a Bearer token with the documented beta header:

const anthropic = createAnthropic({
  apiKey: 'replaced-by-fetch',
  fetch: async (input, init) => {
    const headers = new Headers(init?.headers)
    headers.delete('x-api-key')
    headers.set('Authorization', `Bearer ${tokenFromClaudeCliCredentials}`)
    headers.set('anthropic-beta', 'oauth-2025-04-20')   // documented
    return fetch(input, { ...init, headers })
  },
})

Public host, published header, no guesswork.

There's no equivalent for a ChatGPT subscription, because that credential isn't valid against api.openai.com. The only reachable host is the one the CLI itself uses:

const openai = createOpenAI({
  baseURL: 'https://chatgpt.com/backend-api/codex',
  apiKey: accessTokenFromCodexAuthJson,
  headers: {
    'ChatGPT-Account-ID': accountId,
    'OpenAI-Beta': 'responses=v1',
    originator: 'my_client_name',
    version: installedCodexCliVersion,
    session_id: randomUUID(),
  },
})

This works today. One request, gpt-5.4-mini, a forced tool call, 21,212 input / 84 output tokens, ~30s — correct structured output. But it works by observation, not by contract.

The actual problem

Because nothing here is documented, I can't tell the difference between "supported, just undocumented" and "internal, may vanish next release":

• chatgpt.com/backend-api/codex isn't listed as a client-facing endpoint anywhere I can find.
• originator clearly gates something, but its accepted values and meaning aren't published. I set it to my own client name rather than impersonating codex_cli_rs, which seems like the honest choice — but I'm guessing.
• version is the installed CLI's version, which implies compatibility coupling to a client I'm not.
• #33969 (403 invalid or disabled credential after a version bump) and #29243 (plan type reported inconsistently) both read like this surface shifting under people.

So the practical question for anyone building on this: is it reasonable to ship, or is it a trap?

What would help

Any one of these, roughly in order of usefulness:

1. A documented header contract for third-party clients — an OpenAI-Beta-style opt-in with published semantics for originator, analogous to anthropic-beta: oauth-2025-04-20.
2. An explicit "no" — subscription credentials are for first-party clients; third parties should use a platform API key. That's a completely reasonable answer and I'd implement to it immediately. Right now the absence of a statement is the problem, not the answer itself.
3. A stability note in the CLI docs stating the endpoint is internal and may change, so people can make an informed call.

Related

#24971 asked the adjacent question for native mobile clients and was closed without a response. #33969 and #29243 both involve this endpoint's auth behaviour changing.

I'm not asking anyone to support my use case. A one-line statement of intent — supported, or not — is enough to decide whether to build on it or drop it.

Environment

• codex-cli 0.146.0
• Linux (WSL2), Node 22