API Key Security Feature Requests

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-keys

It 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).

The current message to set an environment variable is unclear — where should I set it? I am running codex on a directory with a .env file that defines an OPENAI_API_KEY so 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 llm also store the keys for different services internally.

There's a huge security implication with just using environment variables. If I want to run codex in 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

line 142: const apiKey = process.env["OPENAI_API_KEY"]; // Use your api key here

if someone needs a solution: mohit-s96#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

It 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).

Perhaps

If OPENAI_API_KEY env var is already set, use that (what is currently done)
If .env file defines OPENAI_API_KEY, then we should support that and use that
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?

If .env file defines OPENAI_API_KEY, then we should support that and use that

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?

#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.

securely store api keys

I'd also like to see the ability for ~/.codex/config.yaml to specify a file path that's a global-level default .env file 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.

feat(tui): add /title terminal title configuration (openai#12334)

fix: critical defects — sandbox approval gate, context compression, +…

fix(rmcp-client): harden MCP OAuth reauth (delete guard + reactive 40…

rdos: dspark_proxy 内化为 provider 中间件——参数注入 + 请求体审计（P1-7）

fix(rmcp-client): harden MCP OAuth reauth (delete guard + reactive 40…

Repo health ratchet gates, PathUri migration epic, offline changelog …

fix(gui): keep pending panel stable during drawer exit

fix(review-batch2): 7 confirmed findings from external review

Navigation Menu

Repository navigation

API Key Security Feature Requests #9

25 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

API Key Security Feature Requests #9

Description

Activity

brianlovin commented on Apr 16, 2025

jonchurch commented on Apr 16, 2025

slhck commented on Apr 16, 2025

mchatzis commented on Apr 16, 2025

mohit-s96 commented on Apr 16, 2025

antoniocascais commented on Apr 16, 2025

tibo-openai commented on Apr 16, 2025

mohit-s96 commented on Apr 16, 2025

tibo-openai commented on Apr 16, 2025

asmeurer commented on Apr 17, 2025

mwolson commented on Apr 18, 2025

asmeurer commented on May 30, 2025

25 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions