Aident AI

Codex "Incorrect API Key Provided: dummy"? Refresh ChatGPT Login
If Codex starts returning 401 Unauthorized: Incorrect API key provided: dummy after you switch Wi-Fi, enable a VPN, or move to a hotspot, do not create an API key named dummy. A current Codex CLI report shows ChatGPT OAuth falling back to an API-key mode with that placeholder after a network change. The reporter restored access with one deliberate codex logout and codex login cycle.
The upstream issue remains open, so treat this as a narrow recovery guide, not a confirmed permanent fix. Preserve your work, finish other Codex sessions that share the login, refresh authentication once, and verify both the login state and a new request.
Confirm This Exact Failure
This guide applies when all of these are true:
You normally use Sign in with ChatGPT, not usage-based API-key authentication.
Codex worked before a Wi-Fi, VPN, proxy, or hotspot change.
Interactive Codex,
codex exec, or a tool that launchescodex app-servernow returns401 Unauthorized.The error names the API key as
dummyeven though you did not configure that value.
Record the exact error, codex --version, operating-system version, installation method, network transition, and UTC time. Do not post ~/.codex/auth.json, Keychain entries, access tokens, refresh tokens, cookies, account email, or unredacted debug logs.
If you intentionally use an OpenAI API key, stop here. A 401 in API-key mode has a different recovery path: validate the key, project, permissions, endpoint, and environment without pasting the secret into Codex or an issue.
Understand What dummy Means
The August 6 report reproduces the failure on Codex CLI 0.145.0 after switching networks. Its redacted debug trace changes from auth_mode="Chatgpt" during a successful request to auth_mode="ApiKey" during the failure. Recovery then does not run because the client no longer considers the request a ChatGPT-authenticated request.
That is evidence from one detailed report, not an official root-cause determination. It does explain why supplying a new API key is the wrong first response for a user who signed in with ChatGPT: the visible dummy value is a symptom of the reported fallback, not a request for a real key.
Older Codex authentication reports provide useful corroboration. In one 401 thread, an OpenAI collaborator recommended codex logout followed by codex login while the team investigated a more robust recovery. Another issue documented environment-based API-key selection taking precedence over a logged-in session. Check the authentication boundary before changing billing credentials.
Prepare for a Safe Login Refresh
codex logout changes stored authentication, so do not let an agent run it automatically. A separate multi-session report describes logout invalidating credentials used by other Codex processes and repeated device-auth recovery reaching a 429 rate limit.
Before you continue:
Save files and inspect the repository diff.
Let active Codex turns finish, then close other Codex CLI, IDE, desktop, and app-server sessions that share this credential store.
Confirm you can complete the normal browser sign-in yourself.
Record the current version with
codex --version.Check the current mode without exposing credentials:
Do not delete the whole ~/.codex directory, edit auth.json, remove Keychain records, or repeatedly rotate credentials. Those actions expand the blast radius and can destroy unrelated session state without proving the cause.
Refresh ChatGPT Authentication Once
Run these commands yourself in a terminal, not through an autonomous coding agent:
Choose Sign in with ChatGPT in the normal login flow. Complete the browser authorization, return to the terminal, and wait for the success message.
If your environment cannot accept the browser callback, Codex also exposes codex login --device-auth. Use it only when the normal flow cannot work, and make one controlled attempt. Do not loop device authorization after a failure or 429 response.
Now verify the stored mode:
Expected result: Codex reports an authenticated ChatGPT login. It should not report API-key authentication unless that is the mode you deliberately selected.
Verify a Fresh Request
Use an empty, disposable test directory rather than a repository with pending work. Run one bounded request:
Success means all of the following are true:
the command returns
auth restored;no WebSocket or HTTPS request returns
401 Unauthorized;the error does not mention
dummy;Codex does not ask for an API key;
no project file changes.
Then open one normal interactive Codex session and send a read-only question. This checks the two surfaces named in the current report without resuming a long-running task first.
If the failure began after a network change, switch only when you can safely test again. A second dummy 401 after the same transition is useful upstream evidence. It is not a reason to automate endless logout and login cycles.
If the 401 Returns
First, update Codex through the same installer or package manager you originally used, then repeat the verification on the latest supported release. Do not mix installation methods or leave multiple Codex binaries on PATH while diagnosing authentication.
Check whether an environment variable is selecting API-key mode, but never print its value:
On PowerShell:
If you use ChatGPT authentication and did not intend to set that variable, remove it from the correct shell or process configuration, start a new terminal, and recheck codex login status. Do not replace it with dummy, an invented value, or a key copied into chat.
If the exact failure persists, add a sanitized reproduction to the existing upstream issue instead of opening a duplicate. Include the version, install method, operating system, network transition, whether OPENAI_API_KEY was set as a yes/no value, the login mode, and whether one manual reauthentication worked. Redact secrets and local identifiers from any trace before attaching it.
For an MCP-specific issuer error that occurs after Codex itself can authenticate, use the separate Codex MCP OAuth issuer guide. That failure belongs to the MCP authorization server, not the Codex account login described here.
Keep Provider Credentials Out of Recovery Prompts
After Codex authentication works again, use typed provider Actions rather than pasting third-party API keys into the repaired session. Aident Loadout can inspect account and Vault state, discover a current Action, validate its schema, and estimate cost before execution.
Give Codex the canonical setup instruction:
Follow https://aident.ai/SETUP.md
Then use this prompt:
Check my Aident Loadout account authentication and Vault status. Search the staging capability catalog for a connected read-only Hacker News search Action, inspect its current schema, and preflight it. If the estimate is free, search for "Codex authentication 401" and return only matching titles and URLs. Do not publish, comment, edit, install, change files, start OAuth, or ask me for a provider key.
Success is measurable: Codex authentication stays valid; Aident account and Vault checks complete; discovery, schema inspection, and preflight succeed; one read-only search runs only if free; no credential appears in the prompt or output; and no external write occurs. Set up Aident Loadout and run the credential-safe check.
Sources
OpenAI Codex issue 37192: OAuth fallback uses
dummyafter a network changeOpenAI Codex issue 32337: multi-session logout and recovery risk
Refresh this guide when issue 37192 changes state, a Codex release removes the fallback, the authentication commands change, or OpenAI publishes more specific recovery guidance.



The one tool
for every tool
your agent needs.
Give any AI agent real capabilities in seconds. Connect 1,000+ tools once, skip the setup headache, and let your agents execute.
