Pointing OpenAI Codex CLI at a third-party gateway

OpenAI’s Codex CLI is a useful tool — fast, agentic, ships with a good default model. The only awkward thing is that it’s wired to api.openai.com by default and the auth model assumes you have an OpenAI key. This post walks through pointing it at a third-party gateway, including ApiLink. The mechanism is the same for any gateway that implements the Responses API.

Why do this

• You want Codex to talk to Claude or Gemini instead of GPT.
• Your team pays a single AI gateway and wants Codex usage to roll into that bill.
• You’re in a region where api.openai.com is hard to reach reliably.
• You want centralized rate limits and per-key spend caps across all your developer tools.

Prerequisites

1. Codex CLI installed (npm install -g @openai/codex or via your package manager).
2. An API key from a gateway that supports the OpenAI Responses API at /v1/responses. ApiLink does; OpenRouter does not (as of 2026-05).
3. The gateway’s base URL — for ApiLink it’s https://apilink.io/v1.

The actual config

Codex respects two environment variables: OPENAI_API_KEY and OPENAI_BASE_URL. Set them and Codex treats your gateway exactly like OpenAI:

export OPENAI_API_KEY="al-yourgatewaykey"
export OPENAI_BASE_URL="https://apilink.io/v1"

codex "refactor the User model to remove the legacy isAdmin flag"

That’s it. Codex will hit https://apilink.io/v1/responses instead of the OpenAI default. Streaming, tool use, and the rich CLI UI all work unchanged.

Picking the model

By default Codex uses gpt-5-codex. To point it at a different model you have two options:

# One-off override
codex --model claude-sonnet-4-5 "your prompt"

# Persistent — set in your shell profile
export CODEX_MODEL="claude-sonnet-4-5"

Verifying it’s actually using your gateway

Easy test: make a request and check the gateway’s usage dashboard. If the call shows up there with the right model and roughly the right token count, the routing works.

Harder test (recommended): set DEBUG=codex*before running Codex. You’ll see the HTTP requests fly past, complete with the target host. Make sure none of them are reachingapi.openai.com— Codex occasionally has backwards-compat code paths that don’t respect the env vars for certain sub-commands.

Same trick for other developer tools

The OpenAI-compatible base-URL pattern works for many of the same tools:

Common gotchas

1. Model name mismatches.Codex’s default model name (gpt-5-codex) is OpenAI-specific. If you don’t override the model, you’ll get a 404 from gateways that don’t resell that model.
2. Rate limits per model. Codex inner loops can hit dozens of requests per task. If your gateway has per-model RPM limits, raise them before scaling Codex usage.
3. Responses API parity. Not every gateway implements /v1/responses. If yours doesn’t, Codex will fail with a 404. The chat-completions endpoint alone is not enough for Codex.
4. Auth header format. Some gateways want Authorization: Bearer xxx; others want a custom header. Standard OpenAI clients always send the Bearer form — if your gateway needs something else, Codex won’t work without a proxy in between.

Closing

Codex CLI plus a multi-model gateway is one of the most underrated developer setups of 2026. You get the agentic UX OpenAI invested in, but with the freedom to route to whatever model is best for the task. Spend caps, audit logs, and a single bill come along for free.

ApiLink is one gateway that implements /v1/responsesend-to-end (streaming, tool calls, the works). If you’re shopping, try ours; if you’re already on another gateway and Codex isn’t working, the most likely cause is a missing Responses API.