Codex integration

Codex calls every model you’ve configured in cc-router through the POST /v1/responses endpoint: whether the upstream speaks the Anthropic or the OpenAI protocol, cc-router translates automatically and dispatches by virtual model.

Codex CLI and Codex Desktop share the same ~/.codex/ config, so editing it once covers both. Edit the two files by hand in the three steps below.

The Setup guide → Codex tab in the cc-router app has the same three-step tutorial, with the config snippets already generated for your current port and token — copying them from there is the easiest way.

Alternative: if you already use cc-switch to manage multiple Codex providers, you can also take the Codex integration (cc-switch) route.

Prerequisites

cc-router installed and configured with at least one virtual model bound (see Getting Started)
Codex CLI or Codex Desktop installed (either one is enough)
Unlike the Claude Desktop integration, the Codex path only uses the HTTP port (23456 by default) — no HTTPS, no CA certificate required

Step 1: Edit config.toml

Add the content below to ~/.codex/config.toml (create the file if it doesn’t exist). It registers a custom provider named cc-router (using the OpenAI Responses protocol) and a profile with the same name:

# cc-router recommended config — generated by the cc-router setup guide
# Usage: codex -p cc-router "your question"
# Just save after editing; codex reads this file on its next launch

[model_providers.cc-router]
name = "cc-router"
base_url = "http://127.0.0.1:23456/v1"
wire_api = "responses"
env_key = "OPENAI_API_KEY"

[profiles.cc-router]
model_provider = "cc-router"
model = "model-sonnet"

If the file already has other settings, just append these two sections at the end. If you added [model_providers.cc-router] or [profiles.cc-router] before, delete the old sections first — TOML doesn’t allow duplicate tables.
base_url must end with /v1; Codex appends /responses to it. Use the actual port shown on cc-router’s Settings page.

Step 2: Edit auth.json

Replace the entire content of ~/.codex/auth.json with the content below (create the file if it doesn’t exist):

{
  "OPENAI_API_KEY": "<cc-router token>"
}

OPENAI_API_KEY is your cc-router token — the same one Claude Code uses; you can find it on cc-router’s Settings page. env_key = "OPENAI_API_KEY" in config.toml tells Codex to authenticate with this field; when cc-router authentication is off, any value works.
Back it up first: if you’ve signed in to Codex with a ChatGPT account, auth.json holds those official credentials. Make a copy of the original file before replacing it; to switch back to the official login later, rename the backup to its original name.
If you regenerate the token in cc-router’s Settings, come back and update this file.

Step 3: Launch Codex

In a terminal, launch Codex CLI with the profile via -p cc-router:

codex -p cc-router "your question"

Codex Desktop reads the same config: restart Codex Desktop once after editing, then pick the cc-router profile in the model picker.

Use a different virtual model

The model field under [profiles.cc-router] in config.toml decides which virtual model is used. Change it to any of the following; save, and Codex picks it up on its next launch:

Set `model` to	Best for
`model-fable`	The hardest tasks
`model-opus`	Planning, long-context reasoning
`model-sonnet`	Everyday coding (default)
`model-haiku`	Tool calls, lightweight tasks

Use cc-router’s virtual model names here. Aliases such as gpt-5.5 and gpt-5.4 also work; see API Overview → Virtual models and aliases for the mapping.

If Codex and cc-router run on different machines, first set the listen address to LAN (0.0.0.0) in cc-router’s Settings, then replace 127.0.0.1 in base_url with the LAN IP of the machine running cc-router — the /v1 suffix must stay:

base_url = "http://192.168.1.50:23456/v1"

Verify

Run one Codex conversation, then open Request logs in cc-router: the Client column should show Codex CLI or Codex Desktop, the Virtual model column the matching slot, and the Real model column the upstream model the request was finally routed to.

The Client access table on the Live routing page also marks Codex as connected.

Troubleshooting

404 Not Found — base_url is missing the trailing /v1. cc-router’s Responses endpoint is at /v1/responses.
401 Unauthorized — the token in auth.json doesn’t match cc-router’s current token (for example, it was regenerated). Fill it in again as in Step 2.
Requests don’t go through cc-router — the CLI was launched without -p cc-router, or Codex Desktop wasn’t restarted after the config change.
Wrong model or model_not_found — the model field is misspelled. A misspelled name falls through to the fallback virtual model — use a virtual model name from the table above.
Connection refused — the cc-router proxy isn’t running, or the port in base_url doesn’t match the actual port.

Security notes

The token in auth.json is a credential that grants access to all your upstream subscriptions, and it’s stored in plaintext — do not leak it or commit it to a repository.
Only expose the cc-router port on a trusted LAN; assess the risk yourself before exposing it publicly, and harden it with a reverse proxy plus an auth layer.