Use Codex's custom-provider configuration when you want its main inference traffic to go through a gateway. OpenAny can be the account and model-access layer, while the same balance also supports separate data and tool API calls.
There is one prerequisite you must not skip: current Codex gateway configuration uses Responses, not just Chat Completions. This guide supplies a configuration pattern, not a claim that a particular OpenAny route has passed Codex acceptance.
Establish compatibility before editing
The reviewed OpenAny gpt-5.5 public example exposes /v1/chat/completions. That evidence alone does not verify /v1/responses. Do not turn a model listing into an unsupported integration promise.
| Requirement | Evidence to obtain |
|---|---|
| Responses endpoint | Current OpenAny route documentation or explicit provider confirmation |
| Streaming | A small approved request using the actual client |
| Tool round trip | Tool invocation followed by a correctly associated result |
| Session continuation | Follow-up works without lost state or unsupported response references |
| Model metadata | Context/output limits and capabilities appropriate for Codex |
If this evidence is missing, keep your current Codex provider and use OpenAny as a tool instead. That is a valid integration, but a different one.
Proposed config.toml
Back up the existing user file and merge the settings rather than appending duplicate tables. These are the default locations:
- macOS/Linux:
~/.codex/config.toml - Windows:
%USERPROFILE%\.codex\config.toml
The placeholder below is deliberate. Replace it only with a route ID whose Responses support has been established.
model = "REPLACE_WITH_VERIFIED_RESPONSES_MODEL"
model_provider = "openany"
web_search = "disabled"
[model_providers.openany]
name = "OpenAny"
base_url = "https://api.openany.si/v1"
env_key = "OPENANY_API_KEY"
wire_api = "responses"
requires_openai_auth = falseKeep top-level settings above TOML tables. If you already have model, model_provider or an openany table, update that entry rather than declaring it twice. Preserve unrelated settings and any organization-managed policy.
Make the OpenAny key available through your approved secret-management method in the process that launches Codex. The key is not a TOML value. A GUI launched from the desktop may not inherit terminal environment variables. Do not add a ChatGPT credential or browser OAuth configuration unless that authentication flow is actually supported by your gateway.
Validate a small session, not just syntax
With explicit budget approval, test one short response, streaming, a harmless read-only tool call and a follow-up. Check the actual destination and OpenAny usage record. A configuration file that parses is not proof that the model, transport and tool semantics work together.
Custom aliases may also require model metadata. Do not point model_catalog_url at OpenAny's AGENT.md, /v1/models or a price JSON merely because those URLs exist: Codex catalog discovery has its own schema. Add metadata only through a documented compatible source or reviewed local catalog.
Rollback means restoring the previous provider/model configuration and launch environment. It does not require deleting stored credentials or reinstalling Codex.
A useful fallback: keep the main model, add OpenAny tools
The OpenAny agent instructions describe the CLI and skill path. Codex can then discover APIs or call another model as a tool without changing its main inference provider. This is often the better first step when you need external data immediately and gateway transport still needs verification.
Use with your Agent
Prepare the change and missing-evidence checklist before authorizing any request.
Make this example yours
Check Responses compatibility for gpt-5.5 and prepare a minimal Codex config.toml change.
Task preview
Read https://openany.si/AGENT.md and follow its setup and credential-safety instructions. Task: Prepare a reversible Codex custom-provider configuration for OpenAny using gpt-5.5 only if the exact route supports the current Codex Responses protocol, streaming and tool-follow-up behavior. Read official Codex gateway documentation and current OpenAny public examples. A Chat Completions template is not proof; if Responses support is unverified, stop at a proposed configuration and report the missing acceptance evidence. Inspect only approved configuration paths, back up and merge existing TOML without duplicate keys or tables, and keep the key in an explicitly authorized OPENANY_API_KEY environment variable. Never ask for secrets in chat or search for them. Do not edit files without approval, send paid requests, install a substitute transport, top up or claim that a skill changes Codex's main model. Return prerequisites, a config proposal, rollback and a budget-gated test plan. Guide: https://openany.si/guides/codex-openany-config-toml/ Ask for a budget and approval before billable requests. Never request credentials in chat. Do not substitute providers or execute other actions without approval. Preserve sources and timestamps; report missing data and actual results honestly.
Explore OpenAny, or use the native-client alternatives for Claude Code and Cursor.
Sources
Frequently asked questions
Can I set wire_api to chat?
Use the current documented Responses transport. A Chat Completions endpoint alone does not establish current Codex compatibility.
Where does config.toml live?
The default user configuration is ~/.codex/config.toml on macOS/Linux and %USERPROFILE%\.codex\config.toml on Windows.
Is there another way to use OpenAny in Codex?
Yes. The OpenAny skill can add API and model tools while leaving Codex's main model connection unchanged.