docs: clarify whether codex-lb-style multi-account ChatGPT-auth proxies are supported

What is the type of issue?

Documentation is missing.

What is the issue?

The Codex authentication documentation describes custom model providers and says that requires_openai_auth = true can be useful when accessing OpenAI models through an LLM proxy server. However, I could not find an official statement that distinguishes a transparent single-account proxy from a third-party proxy that terminates ChatGPT authentication for multiple accounts and selects among them.

I am asking specifically about the open-source third-party project codex-lb, and more generally about tools with the same architecture. I am not asking OpenAI to endorse or review the security of this particular third-party project.

Please evaluate the following local/private scenario:

• one human operator, with no access sold or shared with other people;
• the official Codex client points to a loopback custom base URL;
• the proxy stores ChatGPT/Codex OAuth credentials locally for multiple accounts that the operator is legitimately authorized to use;
• the proxy chooses an eligible account per request, maintains session affinity, reads quota/reset metadata, and presents one local endpoint over the separate upstream accounts;
• each upstream account's limits remain enforced by OpenAI;
• the proxy may send small automated warm-up/prestart requests before interactive use;
• there is no public endpoint and this is not a multi-tenant service.

The current individual Terms of Use say that users may not share account credentials or make an account available to someone else, and may not circumvent rate limits or restrictions. The technical Codex documentation does not say whether the local/private scenario above is permitted use, unsupported use, or prohibited circumvention.

Could OpenAI clarify:

1. Is a transparent, local, single-account proxy supported/permitted when it simply forwards one user's own Codex traffic?
2. Is the local/private multi-account scenario above permitted when there is only one human operator and no credential sharing with another person?
3. Do account selection, quota-aware routing, failover, or warm-up/prestart requests count as circumventing or aggregating usage limits, even when OpenAI still enforces every upstream account's individual limit?
4. Does the answer differ for individual Plus/Pro accounts and Business/Enterprise seats?
5. Would a shared, public, or multi-tenant version necessarily need to use the API Platform rather than ChatGPT subscription authentication?
6. What is the officially supported architecture for a user who needs higher aggregate Codex capacity, failover, or centralized observability: API keys with organizations/projects, a Business/Enterprise workspace, or something else?
7. If GitHub maintainers cannot give an authoritative terms/policy answer, which exact OpenAI support channel and request category should be used to obtain a written determination?

A short documentation note separating technical custom-provider/proxy support from subscription credential pooling and usage-limit policy would remove substantial ambiguity. Related issue #34608 asks about a single subscriber using a transparent observability gateway, but it does not address multi-account credential termination, quota-aware routing, or automated warm-up traffic.

No credentials, account identifiers, private logs, or user prompts are included in this report.

Where did you find this issue?

• Codex authentication: https://developers.openai.com/codex/auth
• Codex basic configuration: https://developers.openai.com/codex/config-basic
• OpenAI Terms of Use: https://openai.com/policies/terms-of-use/
• Related single-account proxy request: https://github.com/openai/codex/issues/34608

Start with the Codex authentication and basic configuration pages cited in the issue, then review related issue #34608 and the linked Terms of Use. Done means maintainers provide an authoritative note distinguishing technical proxy configuration from subscription credential pooling and usage-limit policy, or identify the exact support channel for that determination.