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.
Esta página está escrita em inglês. Os termos que explica são os que se procuram em inglês, e um termo técnico traduzido é um termo diferente.
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.