ChatGPT (Codex)
GPT models on a ChatGPT Plus/Pro plan, via the Codex CLI login. It runs on your own machine, so there is no key and nothing to pay.
本页正文为英文。它解释的术语是人们用英文检索的术语，而译过的术语已经是另一个术语。
What the harness already knows
| Provider id | openai-codex |
| Base URL | https://chatgpt.com/backend-api |
| Protocol | openai-codex |
| API key | None — the endpoint is local. |
| Model discovery | No — models come from the catalogue and from what you configure. |
Connecting it
Nothing to configure and no key to obtain. Start the server on its usual port and the provider appears in the model picker; the harness asks it for its own model list rather than shipping one.
Worth knowing
The backend the Codex CLI talks to. It is a different wire format from the OpenAI Responses API and it takes no API key at all — only a ChatGPT OAuth token, which this build reads from the Codex CLI's own credential file rather than running a second login of its own. excludeModels lists the models this backend refuses to a ChatGPT account outright — verified against a live Plus account; a plan that does serve one can drop it from this list in a user catalog.
Pointing it somewhere else
A regional host, a gateway, or a server of your own. Overrides in ~/.oharness/config.json are field level, so changing the endpoint does not mean restating the rest of the provider — this is the whole block, shown holding the default so the shape is clear:
{
"providers": {
"openai-codex": {
"baseUrl": "https://chatgpt.com/backend-api"
}
}
}What you get either way
The same agent loop, the same tools, the same MCP servers and the same permission rules, whichever provider is underneath — and switching between them mid-session converts nothing, because history is never stored in a vendor’s shape. What an agent harness is covers why that is the hard part, and the providers reference covers the catalogue itself.