Support using OPENAI_API_KEY without writing to auth.json

@nihaals thanks for providing the snippet on how to do that with a custom provider. It's not idea, and I 👍 this issue b/c I'd like the process to be simpler, but very helpful anyway to have a workaround documented.

Older versions of the CLI supported implicit logins using OPENAI_API_KEY when using the default model provider. We removed this in favor of explicit logins. Implicit logins result in a bunch of other complications and undesirable behaviors, especially given that codex auth is shared between the CLI and the VS Code extension.

The CLI still supports implicit login using environment variables with custom model providers and with exec mode.

I think it's unlikely that we'll add back support for implicit logins when using the default model provider — at least not with the OPENAI_API_KEY environment variable.

I understand your concern about having the key written to disk in an unencrypted form. We're looking at ways to better secure it.

Using the OS secret store (keychain, secret service etc.) would be fine for me, although that might be part of a new issue in case some people have a different use-case that needs something like this (e.g. rotating API keys/short-term API keys, although a non-interactive OPENAI_API_KEY=... codex login could work for this).

I'm now using multiple profiles each using a different OpenAI API key so I would also want to be able to do that with the secret store implementation, although if there aren't any plans of breaking env_key then I could also just continue to use my current setup instead of the secret store.

FWIW, my use case is for running Codex in Docker. I have the API key loaded from 1Pass in my terminal session and it gets passed through to the container. I'd like to fully script the run so any kind of required interaction is problematic. I also, as good security practice, try to avoid ever having secrets exposed in plain text files anywhere on the file system.

I don't know the problems with "implicit logins" but I trust they are there. But it's not too difficult to support using the API key and making that explicit:

codex --use-api-key

Or as a config parameter:

use_api_key = true

# OR (at the top level, not requiring a provider)

env_key = "OPENAI_API_KEY"

That way it's still explicit but less hassle to configure than needing to config a custom provider. I wouldn't have even known that was an option if I hadn't found this issue and the example by the OP.

I see this as a sub-issue of the security of the .codex folder. Currently, any accidental inclusion of the .codex folder into a public GitHub project can have security implications. Meanwhile, users might want to have a per-project .codex for several reasons: per-project flexibility of API key and/or billing and/or alternative providers. A second reason is the desire to preserve the conversation logs for various purposes. It hints to me that having a global-local split and allowing inheritable .codex might solve the issue. It would be like VSCode's configurations being split into user vs workspace. It might be a hassle but not solving this issue makes it a security risk.

btw .. would the issue labels auth and custom-model apply to this issue?

I think it's unlikely that we'll add back support for implicit logins when using the default model provider — at least not with the OPENAI_API_KEY environment variable.

This decision is counter intuitive. Many tools on Linux prefer environment variables because they are ephemeral and more secure.

If you don't want to reconsider the decision to remove support for OPENAI_API_KEY, please at least continue to support the workaround that is provided in the first comment of this issue.

A quick note about security. If you supply the OPENAI_API_KEY environment variable, it's probably a good idea to remove it before executing commands from the Codex CLI. You have to add the following in your config.toml:

[shell_environment_policy]
exclude = ["CODEX_HOME", "OPENAI_API_KEY"]