# Codex 401 Incorrect API Key: Outage, Stale Token, or Your Key? > Signed in with ChatGPT and never set a key? That 401 came from OpenAI's September 25, 2026 outage. The URL and key text in the error tell you if yours differs. - URL: https://blog.laozhang.ai/en/posts/codex-401-incorrect-api-key - Published: 2026-10-01 - Updated: 2026-10-01 - Author: LaoZhang AI Team (https://blog.laozhang.ai/en/about) - Category: AI - Tags: Codex, 401 Unauthorized, Incorrect API key, Codex CLI, Troubleshooting --- If you sign in to Codex with ChatGPT and have never configured an API key, `unexpected status 401 Unauthorized: Incorrect API key provided` does not describe a key of yours. On September 25, 2026, that exact message hit ChatGPT-sign-in users across the CLI, the desktop app, and the VS Code extension for about 74 minutes because of a fault inside OpenAI. Nothing on your machine caused it, and nothing on your machine fixed it. If the error is still appearing after that date, or you use an API key or a custom provider, the cause is different. The error line itself tells you which case you are in: look at the URL it names, the key text it prints, and how you are signed in. ## "Incorrect API key provided" on ChatGPT sign-in: the September 25 outage The September 25 error was a server-side failure, and OpenAI has said so in writing. Its [incident write-up](https://status.openai.com/incidents/01M3DCNWMW57HYK8FJ5FBFPA39/write-up) states that between approximately 3:33 p.m. and 4:47 p.m. PDT (22:33–23:47 UTC), Codex users signing in with ChatGPT saw authentication errors (401) and gateway errors (502). Access through customer-provided API keys was unaffected. The cause was a false alarm in OpenAI's own security tooling. A credential leak detection system flagged credentials used for communication between internal services that support Codex. Those credentials were then revoked by a manual operation that bypassed existing safeguards. OpenAI confirmed the triggering traffic was legitimate and the credentials had not leaked. Engineers re-enabled the original credentials by 4:39 p.m. PDT, and the write-up describes service as "largely recovered" by about 4:47 p.m. During the incident, the full error looked like this in reports on [openai/codex issue #48237](https://github.com/openai/codex/issues/48237) and [#48241](https://github.com/openai/codex/issues/48241): ```text unexpected status 401 Unauthorized: Incorrect API key provided: sk-svcac***...***fvMA. You can find your API key at https://platform.openai.com/account/api-keys., url: https://chatgpt.com/backend-api/codex/responses, cf-ray: ..., request id: ... ``` Different people on macOS, Windows, and Linux posted the same masked key, beginning `sk-svcac` and ending `fvMA`. A key that is identical across unrelated accounts cannot belong to any of them. That fits OpenAI's account of revoked internal credentials, although OpenAI has not said what the `sk-svcac` prefix means or confirmed that the printed key was one of those credentials. Two time windows circulate for this incident, and they measure different things. The write-up's impact window is about 74 minutes. The [status page incident](https://status.openai.com/incidents/01M3DCNWMW57HYK8FJ5FBFPA39) ran from its first update at 22:58 UTC to "Resolved" at 23:54 UTC, which is 56 minutes. The first status update came roughly 25 minutes after the impact began, so a status page that looked green did not mean the problem was local. ![Timeline of the September 25 Codex outage in UTC, showing the 74-minute impact window, the 56-minute status page incident, and four updates between 22:59 and 23:51](https://blog.laozhang.ai/posts/en/codex-401-incorrect-api-key/img/codex-401-outage-timeline.webp) ## Which 401 you have: the URL, the key text, and your sign-in method Three details separate the cases. Two are in the error line. The third comes from one command: ```bash codex login status ``` During the outage, affected users reported this command printing `Logged in using ChatGPT` while requests still failed. The local sign-in was intact. | What the error and `codex login status` show | Where the 401 comes from | What to do | | --- | --- | --- | | URL is `chatgpt.com/backend-api/codex/responses`, key starts with `sk-svcac`, you are logged in using ChatGPT | OpenAI's backend. This is the September 25 pattern. | Check the status page and wait. Leave local files alone. | | URL is `api.openai.com/v1/responses`, key text is `dummy`, you are logged in using ChatGPT | A token refresh failed and Codex sent a placeholder instead, according to a user report | Sign out and sign back in. | | Body is `{"detail":"Unauthorized"}` with a message that your refresh token was revoked | Your ChatGPT session. This is a different 401 with no "Incorrect API key" text. | Sign out and sign back in. | | You are signed in with an API key, and the masked key matches one you created | The OpenAI Platform rejecting your key | Fix or replace the key. | | URL is neither `chatgpt.com` nor `api.openai.com` | Your custom provider or gateway | Fix that provider's key and base URL. | ![Five Codex 401 error patterns matched to their source and fix: OpenAI backend outage, failed token refresh, revoked ChatGPT session, rejected API key, and custom provider](https://blog.laozhang.ai/posts/en/codex-401-incorrect-api-key/img/codex-401-source-map.webp) The `dummy` row comes from [issue #37192](https://github.com/openai/codex/issues/37192), opened in August 2026 against CLI 0.145.0. The reporter switched networks, the ChatGPT token refresh failed, and Codex fell back to a hard-coded `dummy` key against `wss://api.openai.com/v1/responses`. That code-path analysis is the reporter's own. The issue remains open, and OpenAI has not confirmed it or named a fixed version. The distinguishing text is still reliable as a signal: `dummy` and an `api.openai.com` URL point at your local session, not at an outage. If you are logged in using ChatGPT but the error names a key you do not recognize, also check whether an environment variable is overriding your setup. This prints variable names only, so no secret ends up in your scrollback: ```bash env | grep -E 'OPENAI_API_KEY|CODEX_API_KEY|OPENAI_BASE_URL' | cut -d= -f1 ``` ## During an outage: what helps and what costs you something When the first row of the table matches, the only useful actions are confirming the incident and deciding whether to switch sign-in methods temporarily. Everything else is wasted effort or worse. **Confirm it is server-side.** Check [status.openai.com](https://status.openai.com) and the newest issues on the openai/codex repository. On September 25, an OpenAI maintainer replied on issue #48237 at 22:59 UTC that the team was aware. At 23:30 UTC the same maintainer called it a widespread outage and wrote, "No need to post additional reports or /feedback." At 23:51 UTC came the note that recovery was "rolling out through clusters," which is why some users came back later than others. **Do not delete `~/.codex/auth.json` or other state files.** Your cached sign-in was not the problem, so removing it only forces a fresh sign-in against a service that is still failing. One widely shared fix from the day after the incident goes further and removes `state_5.sqlite` files too, with a warning that locally cached task and session state may go with them. OpenAI's [authentication documentation](https://learn.chatgpt.com/docs/auth) does not mention that file or list deleting it as a recovery step. **Do not downgrade, reinstall, or reboot as a fix.** One user reported recovery after downgrading the CLI to 0.148.0, posted at 23:56 UTC, two minutes after the status page marked the incident resolved. Another user reproduced the identical failure on 0.148.0 during the outage. A third reported that a second reboot fixed it, in a time span that overlaps the recovery rollout. These actions coincided with the server coming back. They do not show that the action worked. **Do not create or rotate an API key to "repair" the error.** The message points you to the API keys page because it is the standard text for a rejected key. On the ChatGPT sign-in route you never supplied one. **Switching to API key sign-in is a real workaround, with a cost.** At 23:19 UTC the status page posted, "Login via API key will unblock access at this time." The documented command is: ```bash printenv OPENAI_API_KEY | codex login --with-api-key ``` Before using it, know what changes. API key usage is billed at standard OpenAI Platform API rates and does not draw on the usage included in your ChatGPT plan. Some features that depend on a ChatGPT workspace or cloud services are limited or unavailable, and Codex cloud works only with ChatGPT sign-in. The CLI and the IDE extension share one credential cache, so the switch applies to both. In a managed environment with `forced_login_method = "chatgpt"`, Codex will sign you out and exit instead. Once the incident is over, run `codex logout` and then `codex login` to return to your plan. [Codex API Key vs Subscription: Which Route Should You Use?](https://blog.laozhang.ai/en/posts/codex-api-key-vs-subscription) covers what each sign-in method includes and what bills it. ## Still getting the 401 after the outage: sign in again, then check the network Once the status page is green, a persistent 401 on ChatGPT sign-in is most likely a session that needs renewing. Sign out, sign in, and confirm: ```bash codex logout codex login codex login status ``` `codex logout` clears the stored credentials for both the CLI and the extension, so you will sign in once and both pick it up. ChatGPT sign-in tokens normally refresh automatically during use. The `dummy` key and the "refresh token was revoked" message are both signs that this refresh broke, and a fresh sign-in replaces the tokens. If the sign-in step itself fails, the problem has moved: see [Codex Token Exchange Failed 403: Diagnose Login, Proxy, Region, and Cached Auth](https://blog.laozhang.ai/en/posts/codex-token-exchange-failed-403). If a clean sign-in succeeds and requests still return 401, look at what sits between Codex and OpenAI. Check the environment variables above, and check `config.toml` for a provider you forgot about. On Windows, one user's report is worth a look. In [issue #48316](https://github.com/openai/codex/issues/48316), a Codex Desktop update moved `codex.exe` into a new versioned folder, and Malwarebytes treated it as a new program and blocked its outbound HTTPS. The logs showed `Workspace routing is unavailable` and `Desktop network policy does not allow this destination`, yet the interface displayed the same 401 Incorrect API key message. This is a single report from the night of the outage, the issue is open, and OpenAI has not confirmed the cause. If you run a third-party firewall and the error began right after a desktop update, check whether the new executable is allowed. ## API key sign-in or a custom provider: the 401 is about your credential When `codex login status` shows API key sign-in and the masked key in the error matches one you created, the message means what it says. OpenAI's [API error reference](https://developers.openai.com/api/docs/guides/error-codes#api-errors) lists the cause of `401 - Incorrect API key provided` as "The requesting API key is not correct." Its advice is to ensure the key is correct or generate a new one. In practice, check these in order: 1. The key still exists on the API keys page and has not been revoked or deleted. 2. The value in your shell is complete, with no trailing whitespace or stray quote characters from a copy and paste. 3. The key you fixed is the one Codex is using. After changing the environment variable, run the `codex login --with-api-key` command again so the stored credential matches. The same reference lists other 401 messages with other causes: invalid authentication, an account that is not a member of an organization, and an IP address that is not authorized. If your text differs from "Incorrect API key provided," follow that message instead. With a custom model provider, neither OpenAI's outage nor your ChatGPT session is involved. The authentication documentation gives three options for a provider entry. `requires_openai_auth = true` uses your OpenAI sign-in and ignores `env_key`. `env_key` names the environment variable holding that provider's key. Setting neither means Codex sends no authentication at all. A 401 here usually means the variable named in `env_key` is empty in the shell that launched Codex, holds a key for a different service, or the base URL points somewhere the key is not valid. [Codex Custom Provider Setup: API Key, Base URL, and Auth](https://blog.laozhang.ai/en/posts/codex-config-toml) walks through each field. ## When to stop local fixes and what to send OpenAI support Stop troubleshooting on your machine when all four of these are true: the status page shows no Codex incident, `codex login status` shows the sign-in method you expect, a fresh `codex logout` and `codex login` did not help, and no environment variable, custom provider, or firewall is in the path. At that point the failure is on an account or server side you cannot inspect. OpenAI's error reference asks for specific details when an error persists: the model you were using, the error message and code, the request data and headers, and the timestamp and time zone of the request. For Codex, the error line already carries two useful identifiers, the `request id` and the `cf-ray` value. Copy the whole line. Add your Codex version, operating system, and the output of `codex login status`. Do not attach `~/.codex/auth.json`. It contains access tokens, and OpenAI's documentation says to treat it like a password and keep it out of tickets and chats. The masked key shown in the error is safe to share. A raw API key is not. If your failure is a different final line, such as `exceeded retry limit`, a 429, or a disconnected stream, start with [Codex 401, 429, and Stream Disconnected: Find the Failing Layer](https://blog.laozhang.ai/en/posts/codex-exceeded-retry-limit-429). ## Questions people asked during the Codex 401 outage ### Was my account banned when Codex said "Incorrect API key provided"? No, the outage error had nothing to do with your account standing. On September 25, the same masked key appeared for many unrelated users at once, and service returned without any action on their accounts. OpenAI's write-up attributes the errors to its own revoked internal credentials. ### How do I update the API key for Codex? Set the new value in `OPENAI_API_KEY`, then run `printenv OPENAI_API_KEY | codex login --with-api-key`. This matters only if you use API key sign-in. If `codex login status` prints `Logged in using ChatGPT`, there is no key to update. ### Will the usage I lost during the outage be restored? A Codex lead at OpenAI posted on X after recovery: "we're back in action and we'll reset usage limits for all paid users across codex and ChatGPT work." The post is quoted in an [OpenAI Developer Community thread](https://community.openai.com/t/codex-is-down-confirmed-by-openai/1400811). Neither the status page nor the incident write-up mentions a reset, so treat it as a stated intention and check your own usage panel. ### Could the same Codex 401 outage happen again? OpenAI listed three follow-ups in the write-up: stronger safeguards on operations that affect internal service credentials, faster tooling to restore mistakenly disabled credentials, and a change to how internal services authenticate so they depend less on this type of credential. These are stated plans. If the `sk-svcac` pattern reappears, the first row of the table above applies again: check the status page before touching anything local.