Codex CLI BYOK: Bring Your Own API Key

Codex CLI supports authentication with your own OpenAI API key — this is what "bring your own key" (BYOK) means in this context. Instead of using a subscription or a Codex-specific plan, you point the CLI at an API key you generate from your OpenAI account and usage is billed directly to that key.

The API key determines the billing, the model access, and the rate limits you have. It does not change how you use the tool or what the project context needs to contain. Tools like fenbs keep reusable project context and setup decisions available regardless of which key or model configuration the CLI uses.

What BYOK means for Codex CLI

By default, Codex CLI uses Anthropic's or OpenAI's own authentication depending on the version and configuration. With a BYOK setup, you provide an API key that the CLI sends with each request. The provider's API receives the request, authenticates it against your key, and bills the usage to your account.

For teams or organizations, BYOK is often the practical path: you control the key, you control the spending, and you can rotate or revoke the key without changing your subscription. You can also use a key associated with a specific project or budget if your provider supports that.

How to set up your API key

1. Generate an API key from your provider's dashboard. For OpenAI, this is at platform.openai.com under API keys. Store it somewhere secure — a password manager, a secrets manager, or an environment variable in your shell profile.
2. Set the key as an environment variable before running Codex CLI. The variable name depends on the provider; for OpenAI it is OPENAI_API_KEY. Check Codex CLI's current documentation for the exact variable it reads.
3. Test the connection with a short task before starting real work. Confirm that the CLI connects, the model responds, and the billing account is the one you expect.
4. For team environments, use a shared secrets manager rather than putting the key in a config file that might be committed to a repository. A committed API key is an immediate security problem.

How subscription access and API billing differ

A subscription to ChatGPT or a Codex plan gives you a set of features and usage at a fixed monthly cost. An API key bills by usage — typically per token processed — with no monthly fee but no included usage either.

For light or occasional use, a subscription can be more cost-effective. For heavy usage or programmatic access, a pay-per-use API key is often cheaper. The right choice depends on how much you use the tool and whether you need features that are only available on a subscription tier.

A subscription does not automatically provide API access. Some providers require a separate API setup even if you have a paid subscription. Check the current documentation for your provider to understand what your plan includes.

What the key does not change

Switching from subscription to BYOK, or from one API key to another, does not affect the project context the CLI works with. The context — your repository, the files, the instructions — is the same regardless of how authentication is configured.

It also does not change what the CLI can do with your codebase. Tool access, file permissions, and the workflow are set by the CLI configuration, not by the key. The key only determines who is billed and which model the API call resolves to.

Rotating and managing API keys safely

An API key is a credential, and credentials should be rotated regularly. For a team, rotating a key means updating the key everywhere it is stored — environment variables on each developer's machine, CI environment secrets, and any other tool that uses it. Document the rotation process once and store it somewhere the team can find it, so the next rotation does not require someone to remember each location from memory.

If you suspect a key has been exposed — it appeared in a log, a screenshot, or a committed file — revoke it immediately in your provider's dashboard and issue a new one. Do not wait to check whether it was actually used. A revoked key that was not abused is a minor inconvenience; an unrevoked exposed key can be expensive.

Set spending limits on API keys, especially for keys used by automated or agent processes. An agent loop that runs more iterations than expected can exhaust a large budget quickly. Most providers let you set a hard cap per key or per project.

How to do this with fenbs

1. Create a free account and add a project for the codebase you are working on.
2. Record the model and provider configuration choices as Decisions and rules: which model you are using, why, and any constraints on usage or cost.
3. Connect Codex CLI to fenbs at /integrations. The connection uses its own authentication through fenbs; it does not share your API key.
4. When you change keys or providers, update the relevant Decisions and rules in fenbs. The project tasks and context do not need to change.
5. Ask Codex CLI to read the project context at the start of each session so the setup decisions are visible regardless of which key it is running on.

For related setup topics, see codex cli commands and codex cli best practices. For working with subagents on larger tasks, see codex subagents.