OpenAI Codex login loop / deleted_agent_runtime_id — fix: remove a stale CODEX_ACCESS_TOKEN env var

[mmontgom1]

OpenAI Codex stuck in an endless login loop / deleted_agent_runtime_id — fix: remove a stale CODEX_ACCESS_TOKEN environment variable

If your Codex desktop app keeps bouncing back to the "Welcome to Codex" login screen no matter how many times you sign in — or the CLI throws a 403 deleted_agent_runtime_id — and it works fine for the same account on another machine or user profile, this is probably you. The cause isn't the app, your account, your network, or your ChatGPT plan. It's an environment variable overriding your login.

Symptoms

Desktop app: ChatGPT sign-in completes (MFA passes, the browser even shows "Signed in to Codex"), then the app drops you right back on the login screen. Forever. The logs show:

error [electron-message-handler] Statsig: error while bootstrapping post-login client errorMessage={"detail":"Unauthorized"}
warning [electron-fetch-wrapper] desktop_fetch_auth_401 ... target="GET https://chatgpt.com/backend-api/wham/tasks/list" ... Unauthorized

CLI: every run fails immediately with:

failed to register agent task with status 403 Forbidden: {
  "error": { "message": "Invalid task registration request.", "code": "deleted_agent_runtime_id" }
}

The tell: it works for the very same account on a different OS user profile or a different computer.

Root cause

A persistent CODEX_ACCESS_TOKEN environment variable is set in your environment. Codex reads it at startup and uses it as the auth source — overriding the normal ChatGPT OAuth login entirely. If that token is an old long-lived "agent identity" token whose agent_runtime_id has since been deleted server-side, every backend call gets rejected as unauthorized. Because the env var always wins, signing in again does nothing: your fresh, valid login is silently discarded in favor of the dead token.

These tokens usually get set when someone configures Codex for headless / CI / automation use (codex login --with-access-token reads CODEX_ACCESS_TOKEN), then forgets the variable is still there.

Why it's so hard to find

The bad token does not live in ~/.codex/, the app's data folder, or your browser cookies. So the usual fixes — reinstalling Codex, deleting ~/.codex, clearing cookies, resetting the profile, switching accounts, even trying API-key auth — all do nothing, because none of them touch your environment. That's also why it works on a clean machine or a different user account: that environment simply doesn't have the variable.

The fix

Check whether it's set, then remove it.

Windows (PowerShell):

# Check (User and Machine scope)
[Environment]::GetEnvironmentVariable('CODEX_ACCESS_TOKEN','User')
[Environment]::GetEnvironmentVariable('CODEX_ACCESS_TOKEN','Machine')

# Remove it (whichever scope it was set in)
[Environment]::SetEnvironmentVariable('CODEX_ACCESS_TOKEN', $null, 'User')

macOS / Linux:

echo "$CODEX_ACCESS_TOKEN"
# if set, remove the line that exports it from ~/.zshrc, ~/.bashrc, or ~/.profile

Then open a brand-new terminal (or sign out and back in) so running processes drop the stale value — env-var changes only apply to newly launched processes. Confirm it's gone (echo $env:CODEX_ACCESS_TOKEN on Windows / echo "$CODEX_ACCESS_TOKEN" elsewhere returns blank), then launch Codex and sign in normally.

While you're at it, check for other auth overrides that can cause similar confusion: OPENAI_API_KEY, OPENAI_BASE_URL, and CODEX_HOME.

Takeaway

When Codex auth misbehaves and a fresh login won't stick, check your environment variables before you reinstall or wipe anything. A stale CODEX_ACCESS_TOKEN silently overrides OAuth, and no amount of app-side cleanup will fix it.