Codex CLI picks up OPENAI_API_KEY from project .env (via shell auto-loading), causing 401 “AK/SK” errors and confusing /status

Resolved 💬 6 comments Opened Aug 15, 2025 by ac1982 Closed Nov 2, 2025
💡 Likely answer: A maintainer (seratch, member) responded on this thread — see the highlighted reply below.

What version of Codex is running?

0.21.0

Which model were you using?

gpt-5

What platform is your computer?

Darwin 24.6.0 arm64 arm

What steps can reproduce the bug?

What steps can reproduce the bug?

  1. In any project folder, create a .env file containing:

``ini
OPENAI_API_KEY=sk-<some-other-key>
``

(Many shells/IDEs auto-load .env automatically — e.g., direnv, zsh-dotenv, VS Code terminal.)

  1. From that project directory, run:

``bash
codex --login # choose “Sign in with ChatGPT”
codex
``

  1. Ask Codex to perform any action (e.g., pls run npm lint, and if problems, try to fix them.).

What is the expected behavior?

What is the expected behavior?

  • When signed in via ChatGPT, Codex should use the token generated by that login, not silently override it with OPENAI_API_KEY from the local environment.
  • /status should display which credential is actually being used (ChatGPT token or environment key) and clearly indicate when an override is happening.

What do you see instead?

Additional information

  • Actual result: 401 Unauthorized errors such as:

``
AuthenticationError: the API key or AK/SK in the request is missing or invalid
``

even though /status still shows:

``
Provider: OpenAI
Model: gpt-5
Signed in with ChatGPT (Plan: Plus)
``

  • Removing or renaming OPENAI_API_KEY in .env immediately resolves the problem.
  • Workarounds:

``bash
env -u OPENAI_API_KEY codex
``

or rename the variable to something like APP_OPENAI_API_KEY.

  • Suggestions:
  • Add /status transparency for credential source.
  • Warn when environment variables override ChatGPT sign-in.
  • Provide a --ignore-env flag.

Additional information

_No response_

View original on GitHub ↗

6 Comments

seratch member · 1 year ago

I tried to see the error you're encountering, but it looks like codex itself doesn’t fail under these conditions. Could it be that some of your command executions, which rely on the OPENAI_API_KEY environment variable, are failing instead? If that’s the case, I understand how frustrating it must be, but I’m not sure it would be right to modify the environment variables on the codex side.

jiangying000 · 1 year ago

I am seeing the same issue, I can't get the {sign in with ChatGPT} option

once change directory to somewhere without a .env file(the file has openai key set), the issue disappears.

hourianto · 1 year ago

I also have the same issue, if there's an .env file present in the project folder where I launch Codex, it will first get OPENAI_API_KEY from that file, not from the environment variables in the shell, which is really inconvenient.

For now I had to create a separate model provider with a different env_key, but I hope there will be an easier solution soon.

imajes · 1 year ago

I don't entirely know if this is the reason, but it is related:

in config.toml, i had a block like this, which i believe was _historically_ correct:

[model_providers.openai-responses-completions]
name = "OpenAI using Responses Completions"
base_url = "https://api.openai.com/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"

and then wired up the gpt5 profile as such:

[profiles.gpt5]
model = "gpt-5"
approval_policy = "on-request"
model_reasoning_effort = "high"
model_reasoning_summary = "detailed"
model_provider = "openai-responses-completions"

It turns out that that provider is _not correct_ for using ChatGPT Plus/Pro credentials. By removing the model_provider= line from the profile, i stopped getting auth errors.

etraut-openai contributor · 9 months ago

The CLI no longer implicitly logs in using the env variable. You now must explicitly log in using codex login --api-key or go through the TUI-based login flow.