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?
- In any project folder, create a
.envfile containing:
``ini``
OPENAI_API_KEY=sk-<some-other-key>
(Many shells/IDEs auto-load .env automatically — e.g., direnv, zsh-dotenv, VS Code terminal.)
- From that project directory, run:
``bash``
codex --login # choose “Sign in with ChatGPT”
codex
- 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_KEYfrom the local environment. /statusshould 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_KEYin.envimmediately resolves the problem. - Workarounds:
``bash``
env -u OPENAI_API_KEY codex
or rename the variable to something like APP_OPENAI_API_KEY.
- Suggestions:
- Add
/statustransparency for credential source. - Warn when environment variables override ChatGPT sign-in.
- Provide a
--ignore-envflag.
Additional information
_No response_
6 Comments
I tried to see the error you're encountering, but it looks like
codexitself doesn’t fail under these conditions. Could it be that some of your command executions, which rely on theOPENAI_API_KEYenvironment 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.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.
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.https://github.com/openai/codex/pull/2342
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:
and then wired up the gpt5 profile as such:
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.The CLI no longer implicitly logs in using the env variable. You now must explicitly log in using
codex login --api-keyor go through the TUI-based login flow.