Sign in with API key via environment variable cannot be used if ChatGPT subscription login is active

[gh640]

What version of Codex is running?

codex-cli 0.30.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?

1. Install Codex CLI 0.30.0
2. Set a valid environment variable OPENAI_API_KEY
3. Run codex --config preferred_auth_method='chatgpt'
   • Login with ChatGPT Plus, Pro or Team plan account and close the session.
4. Run codex --config preferred_auth_method='apikey'
5. Select 2. Provide your own API key

What is the expected behavior?

Codex CLI is usable with API key even with ChatGPT subscription login is active.

What do you see instead?

The message "To use Codex with the OpenAI API, set OPENAI_API_KEY in your environment" continues to be displayed even with OPENAI_API_KEY is set and codex session doesn't start.

Additional information

Related issues

• #2733
• #2992

I confirmed this occurs with the latest 0.30.0 in my environment.

[gh640]

Current workarounds that work are to delete auth.json or to manually set OPENAI_API_KEY in auth.json.

related comments:

• https://github.com/openai/codex/issues/2733#issuecomment-3227059115
• https://github.com/openai/codex/issues/2733#issuecomment-3242788809

Screen recording:

https://github.com/user-attachments/assets/76e64a59-1fb2-41d0-acb1-1cbcce2b8abe

[pakrym-oai]

We are working on a fix for this issue.

[anks2k]

I was just starting to use, installed codex and was about to pull my hair out as the key is env var and codex keeps looping like a dj to set the apikey.

[dmatveev]

I can confirm this is an issue, codex-cli 0.34.0

[etraut-openai]

Thanks for the bug report. The next release (0.35.0) will address this by simplifying login in the following ways:

1. If you run codex and have not previously logged in (there's no auth.json file), codex will ask you whether you want to use ChatGPT or an API Key. Once you make this selection, it will save your choice in auth.json and no longer ask you until you log out. The /logout command deletes auth.json.
2. The preferred_auth_method config option is eliminated. It's no longer needed because the last login method is always assumed to be your preferred auth method.
3. Login is now always explicit. You can no longer implicitly log in by defining an env variable. If you want to explicitly log in with an API Key via a script, you can do this with codex login --api-key <key>.

The behavior described above applies only if you're using the default model provider. If you've configured a custom model provider that requires an API key, the key comes from the configured env_key. When a custom model provider is used, you will not see a login menu in the TUI, and auth.json is not used to store your login information.

Going forward, the login behaviors described above will be consistent across the Codex CLI and IDE extension. Previously, there were subtle and confusing differences between the two.

[Nacho-Larreta]

Hi everyone,

I hit the same issue, but it turned out to be a file‐permissions problem caused by having run codex earlier with sudo. Because of that, some files or directories in the Codex workspace were owned by root, so running without sudo caused failures (os error 13, Permission denied).

Here’s what I observed from the logs:

• “Permission denied (os error 13)” for “rollout recorder” initialization
• Codex was “frozen” in the terminal: when I sent prompts, nothing happened. No exception, no visible error, no output. Just silence.
• Also got messages like “channel closed”, “failed to send message / AddHistory op”, etc.

What fixed it for me:

1. Changed the ownership/permissions of the workspace directory (e.g. ~/.codex) so my normal user has read/write access. sudo chown -R myuser ~/.codex
2. Made sure subsequent runs of codex are without sudo.

After that, everything worked fine again (prompts responded, API key mode worked, etc.).

Hope this helps anyone stuck in a similar situation. Thanks!

[gh640]

@etraut-openai

I confirmed Codex CLI no longer recognizes preferred_auth_method and the authentication process works exactly as you explained with the newer versions. Thanks!