Codex CLI cannot find a custom provider API key.

If Codex CLI says Missing environment variable: OPENAI_API_KEY or names another provider key even though it is set, check which provider Codex selected and which variable its env_key points to. A public Codex issue reports this behavior with custom providers; the reports do not establish a universal cause.

1. Match the active provider to its key variable

In Codex's user configuration, model_provider selects an ID from [model_providers.<id>]. The provider's env_key is the environment-variable name, not the secret value:

model = "your-model-id"
model_provider = "my-provider"

[model_providers.my-provider]
name = "My provider"
base_url = "https://api.example.com/v1"
env_key = "MY_PROVIDER_API_KEY"

Check that the provider ID in model_provider exactly matches the table name and that env_key exactly matches the variable you export. Keep the key value outside config.toml, project files and shared screenshots.

2. Confirm the key is present without printing it

Run this in the same terminal that launches Codex. It reports only whether the variable is non-empty:

if test -n \
  "${MY_PROVIDER_API_KEY:-}"; then
  printf 'MY_PROVIDER_API_KEY is set\n'
else
  printf 'MY_PROVIDER_API_KEY is missing or empty\n'
fi

Replace the variable name with the exact value of env_key. A variable set in another terminal, shell startup file or desktop process is not automatically present in the process that launches this CLI.

3. Test the configured provider selection for one run

Codex documents --config / -c for a one-run override. One workaround reported in issue #52806 was to set the custom provider explicitly:

codex --config 'model_provider="my-provider"'

Run it from the same shell after the non-empty check. If this changes the error, compare the provider selected by your normal launch path with the ID in your config. This workaround does not prove that the provider accepts the key, model or request.

Separate local key lookup from endpoint compatibility

• Missing environment variable: first verify the selected provider, exact env_key name and the process environment. This message alone does not establish whether a request reached the host.
• HTTP response after a request: capture the request path and status before changing credentials. A later 401, 403 or 404 needs a separate auth, access, route or model check.
• Chat Completions-only endpoint: current Codex source accepts the Responses wire API; the legacy wire_api = "chat" setting is removed. Fixing local key lookup does not make a Chat Completions-only service compatible with Codex CLI.

ChinaGenAI currently documents its site API as POST /v1/chat/completions, not /v1/responses. This guide does not claim that Codex CLI can use the ChinaGenAI endpoint. Check the site API's supported route.

For a safe support report, share the Codex version, provider ID, variable name, launch command shape and redacted error. Do not paste the key or a full environment dump. If you are using Qwen Code rather than OpenAI Codex CLI, its settings file and authentication flow are different; see the Qwen Code guide.

Sources and scope

OpenAI's current Codex configuration guide documents custom provider IDs, env_key and one-run --config overrides. In OpenAI Codex issue #52806, the initial report names CLI 0.162.1 on WSL2; later comments describe 0.163.0 on Linux and macOS. The issue remained open when checked on 1 November 2026, with no maintainer diagnosis or fix shown in the public thread. Treat the override as a reported workaround, not a guaranteed fix.

Codex advanced configuration · OpenAI Codex issue #52806 · Codex provider wire API source

Checked 1 November 2026 against the linked official documentation, source and public issue. No provider key, Codex CLI session or inference request was used.