API Key Security Feature Requests
Resolved 💬 13 comments Opened Apr 16, 2025 by asmeurer Closed Aug 7, 2025
💡 Likely answer: A maintainer (jonchurch, contributor)
responded on this thread — see the highlighted reply below.
When you start codex it asks you to put your API key in an environment variable:
Missing OpenAI API key.
Set the environment variable OPENAI_API_KEY and re-run this command.
You can create a key here: https://platform.openai.com/account/api-keysIt would be preferable if it just prompted you for a key and it stored it securely, i.e., in the OS keystore (like the macOS keychain). It would also be better to use a bespoke key for codex rather than just a generic "openai API key".
It would also be nice if it just opened the browser to a page where you authenticate and generated a key for you (Claude Code does this).
13 Comments
The current message to set an environment variable is unclear — where should I set it? I am running
codexon a directory with a.envfile that defines anOPENAI_API_KEYso it must be looking somewhere else. Adding more information about how to set this up in the short term would be useful!This is a grab bag issue of API Token security requests, I'd retitle this "API Key Security Feature Requests" or something.
I specifically want to know what permissions are required, instead of setting a full access token on my env
I second this. Tools like
llmalso store the keys for different services internally.There's a huge security implication with just using environment variables. If I want to run
codexin any terminal session, it would require me to set an API key in my environment for _all_ terminal sessions, meaning that _every_ command-line application I run could possibly have access to that key.A temporary solution to avoid setting a global environment variable is to build from source and change this line to your api key (hard-coding it)
file: codex-cli/src/cli.tsx
if someone needs a solution: https://github.com/mohit-s96/codex/pull/1. it uses node-keytar.
It would be great if the API key could also be read from a file, in addition to environment variables.
This would help avoid storing sensitive keys in shell history via
export.Would accept a contribution here that does this in a principled way and +1 to
Perhaps
1) If OPENAI_API_KEY env var is already set, use that (what is currently done)
2) If .env file defines OPENAI_API_KEY, then we should support that and use that
3) If not set, suggest to create a new api key for codex-cli and paste it in, then store this securely, e.g. keychain on macOS. If we can't store securely automatically, then ask user to store it in a file or their ~/.bashrc, but warn about potential downside of that.
Thoughts?
could be ambiguous as to which key source is being used (keychain vs env variable vs cwd .env file). it could show a message with the source of the key?
https://github.com/openai/codex/pull/122 for .env support
I'm not a security expert. I personally would only do it the secure way, unless you have some major reason not to. The tool is new enough that making people switch is not a big deal. But if you don't want to deprecate the environment variable I'm happy to at least have a way to not have to use it.
I'd also like to see the ability for
~/.codex/config.yamlto specify a file path that's a global-level default.envfile if possible.I see now that codex lets you sign in directly with ChatGPT, which is an improvement. Although the auth token is still stored in a plain text file, and also this does nothing for the use-case of using other providers.
Thanks for the feedback! We recommend using "Sign in with ChatGPT" or you can directly set the API key as an environment variable when you run codex rather than in all sessions if you prefer.