Codex CLI Authentication: Sign In and Check Your Access

Codex CLI can sign in through a browser via the codex auth command, which stores credentials locally, or through an API key set in the environment. Both methods give the agent access to the OpenAI models; the difference is how credentials are stored and which account they belong to. Getting this right is a prerequisite for every other task.

Once the assistant is connected to your account, the useful question becomes: does it have the project context to start useful work? A tool like fenbs keeps rules, task plans and Where we left off outside the session, so an authenticated assistant can read what it needs before it takes a single action.

Two ways to authenticate

The codex auth command opens a browser and walks you through signing in to your OpenAI account. After you approve, the CLI stores a credential locally. When you run codex later, it reads that stored credential automatically. This is the simplest path for individual developers working on their own machine.

The API key method uses an environment variable. Set OPENAI_API_KEY in your shell or in a .env file that your shell loads, and the CLI reads it instead of looking for stored credentials. This is the standard approach for CI pipelines, shared servers, and setups where a browser sign-in is not practical.

export OPENAI_API_KEY=your-key-here

If both a stored credential from codex auth and an OPENAI_API_KEY environment variable are present, the CLI typically uses the environment variable. Check the OpenAI Codex documentation↗ (opens in a new tab) for the exact precedence on your version.

Generate and manage your API key

API keys are created at platform.openai.com in the API keys section. Create a key with a descriptive name so you can identify it later. Store the key securely; it gives full API access to your account for any request the CLI makes.

Do not paste your API key into a code file, a commit, or a shared document. Use environment variables or a secrets manager. If a key is exposed, revoke it immediately from the API keys page and create a new one.

Set a usage limit on the key at platform.openai.com to avoid unexpected charges from a misconfigured headless run. See codex cli headless for the configuration steps for automated runs.

Common account mismatches

The most frequent authentication problem is using a key from the wrong account. If you have a personal account and a work account, check that the key in your environment belongs to the account with the model access and quota you expect.

Organization keys add another layer. Some OpenAI keys are scoped to a specific organization. If Codex CLI reports a model access error after authenticating successfully, check whether the key is an organization key and whether the organization has the model enabled.

If you use codex auth on a shared machine, the stored credential belongs to whoever authenticated last. Other users on the same machine will use your account unless they authenticate with their own. On shared machines, the API key approach with per-user environment variables is cleaner.

Verify that authentication worked

After signing in, run a simple task to confirm the connection:

codex "List the files in the current directory and describe what they do"

If the CLI returns an authentication error, check that the key is correct and not expired. If it returns a model access error, confirm that your account or organization has access to the requested model. If it returns a quota error, check your usage at platform.openai.com.

Use a different model or provider

Codex CLI supports a --model flag to specify which OpenAI model to use. If you need a specific model for a task, check that your account has access to it before starting a long session. Codex CLI is built for OpenAI's API; connecting it to a different provider's API requires a compatibility proxy. The codex cli with ollama guide covers one approach to using a local model through a proxy.

Connect the authenticated CLI to your project context

Authentication connects the CLI to your OpenAI account. It does not tell the agent anything about the project it is about to work on. The first thing a connected agent should do is read the project context: rules, open tasks, and Where we left off.

Keeping that context in a shared tool means every new session, authenticated through any method, starts with the same picture of the work. The agent does not need to be re-briefed by the person each time.

How to do this with fenbs

1. Create a free account and add your project with its current tasks and any standing rules.
2. Authenticate Codex CLI: run codex auth for a personal machine or set OPENAI_API_KEY for a server or CI environment.
3. Connect Codex CLI to fenbs over MCP from Integrations. This uses a separate browser sign-in for fenbs, distinct from your OpenAI authentication.
4. At the start of each session, ask Codex CLI to read the project context from fenbs: rules, open tasks, and Where we left off.
5. Before the session ends, ask it to save progress so the next session picks up from the right point.