›_ Codex Issues
Codex Issues / #15151

Bug: OPENAI_API_KEY env var silently overrides OAuth token, causing misleading 401 error

Open 💬 6 comments Opened Mar 19, 2026 by zizhegao
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug Description

When OPENAI_API_KEY is set in the shell environment (e.g., in .zshrc) and you log in to Codex CLI via OAuth (e.g., a corporate/enterprise ChatGPT account), Codex CLI silently uses OPENAI_API_KEY from the environment instead of the OAuth token for API requests.

This causes a misleading 401 error that looks like a permissions/scope issue with your OAuth account, but the real cause is that the wrong credentials are being used entirely.

Steps to Reproduce

  1. Set OPENAI_API_KEY in your shell environment (e.g., a personal/restricted API key in .zshrc)
  2. Run codex login and complete OAuth login with a corporate/enterprise account
  3. Send any message in Codex CLI

Expected Behavior

After a successful OAuth login, Codex CLI should use the OAuth token for API requests. The OPENAI_API_KEY environment variable should either be ignored when an OAuth session is active, or at minimum a warning should be shown when both are present.

Actual Behavior

Codex CLI uses OPENAI_API_KEY from the environment instead of the OAuth token, resulting in:

Unexpected status 401 Unauthorized: You have insufficient permissions for this operation.
Missing scopes: api.responses.write. Check that you have the correct role in your organization
(Reader, Writer, Owner) and project (Member, Owner), and if you're using a restricted API key,
that it has the necessary scopes.
url: https://api.openai.com/v1/responses

The error message mentions "restricted API key" and "missing scopes" — which correctly describes the env var API key being used — but gives no indication that OAuth credentials are being bypassed. This makes diagnosis extremely difficult.

Why This Is Confusing

The error leads users to believe their OAuth account lacks permissions. Typical debugging steps (logout → delete ~/.codex/auth.json → re-login → reinstall) all fail because the root cause is the environment variable, not the OAuth session.

Workaround

# Temporary fix
unset OPENAI_API_KEY && codex

# Permanent fix via alias
alias codex='unset OPENAI_API_KEY && command codex'

Environment

  • Codex CLI version: 0.114.0
  • OS: macOS
  • Auth method: OAuth (ChatGPT Enterprise workspace via Okta/SAML)

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #13529

Powered by Codex Action

etraut-openai contributor · 4 months ago

Codex doesn't use OPENAI_API_KEY in the way you're describing here. The only place the OPENAI_API_KEY env variable is used in the Codex CLI is in the login flow when you choose "API Key". The CLI uses the OPENAI_API_KEY env variable to pre-populate the API Key value.

Codex does support the CODEX_API_KEY env variable, but only in the non-interactive codex exec subcommand.

So this does not explain the 401 errors you're seeing.

zizhegao · 4 months ago

The exact mechanism may be different from what I inferred, but unset OPENAI_API_KEY && codex reliably fixes the issue for me.

jasonfirkus · 3 months ago

i'm having this same issue too and deleting the OPENAI_API_KEY env var fixed it

earonesty · 3 months ago

codex exec completely fails in the latest version with an api-key-only.. the websockets get 500 errors.

EthanSK · 2 months ago

Adding another confirmed repro from macOS, with one extra clue that made this especially confusing.

What we observed:

  • Codex appeared to "switch back" to using a personal API key after update/relaunch.
  • It looked like the key might be saved somewhere in Codex global config.
  • But on inspection, Codex itself was not storing the key:
  • ~/.codex/config.toml had no OpenAI API key setting
  • ~/.codex/auth.json was in chatgpt auth mode
  • ~/.codex/auth.json had OPENAI_API_KEY: null
  • The actual cause was an inherited OPENAI_API_KEY in the parent shell environment.

Why this is worse than a normal auth mixup:

  • After an update or relaunch, the behavior can look like Codex has remembered or re-saved the API key internally, even when it has not.
  • That sends people looking in the wrong place (~/.codex/*) and makes the product feel like it has silently switched billing/auth mode.

Expected behavior:

  • If ChatGPT/OAuth auth is active, an inherited OPENAI_API_KEY should not silently take precedence.
  • At minimum, Codex should show a very explicit warning / active-auth-source indicator when env-var API auth is overriding an existing ChatGPT session.

Environment:

  • macOS
  • Codex CLI / app using ChatGPT auth
  • OPENAI_API_KEY present in inherited environment, but not saved in Codex config/auth files

So this is not just "401 because wrong credentials". It also creates the false impression that Codex is persisting API-key auth on its own.