Summary
The Sep 26 Codex incident that produced 401 Unauthorized / Incorrect API key provided: sk-svcac... was reportedly mitigated, and several users have confirmed recovery.
However, Codex is still unusable on my Windows PC as of Sep 27 (KST). The current failure persists even after reinstalling the desktop app.
Current behavior
Any prompt, including trivial prompts in a newly created folder/workspace, enters:
Reconnecting... waiting for network
and retries up to 5/5 without completing.
Earlier on the same machine, the same failure path also produced:
401 Unauthorized
Incorrect API key provided: sk-svcac...
Why this report is separate from the Sep 26 outage
Related incident reports such as #48237 and #48306 indicate that the service-side issue was mitigated and that many affected users recovered without local changes.
My environment did not recover after that mitigation, and reinstalling the desktop app did not fix it.
Previous report: #48402
I am opening this as a fresh issue because the continuing post-mitigation behavior may be a separate or residual account/app problem rather than the already-mitigated outage.
Environment / checks already performed
- Windows
- ChatGPT account authentication
codex login status reports: Logged in using ChatGPT- Standalone CLI reports:
codex-cli 0.101.0
OPENAI_API_KEY is not defined in the Windows environment- Creating/opening a brand-new folder/workspace does not help
- Reinstalling the desktop app does not help
- App restart / reauthentication did not resolve the earlier 401 behavior
- At one point,
netstat -ano | findstr :17841 showed no listener after the failed turn had ended
- Model shown in the app: GPT-6 Luna
Steps to reproduce
- Launch Codex on Windows.
- Open any existing workspace or create a new folder/workspace.
- Submit a simple prompt.
- Observe repeated
Reconnecting... waiting for network attempts up to 5/5.
- The request never completes.
Expected behavior
Codex should complete the prompt normally using the authenticated ChatGPT account.
Actual behavior
Codex remains stuck in the reconnect loop and is unusable on this PC even after the reported Sep 26 mitigation and after reinstalling the app.
Request
Could a maintainer please check whether there may be a residual account-side routing/auth/session issue, or advise which specific desktop logs / request IDs / diagnostics would be most useful to collect for this post-mitigation case?
Summary
The Sep 26 Codex incident that produced
401 Unauthorized / Incorrect API key provided: sk-svcac...was reportedly mitigated, and several users have confirmed recovery.However, Codex is still unusable on my Windows PC as of Sep 27 (KST). The current failure persists even after reinstalling the desktop app.
Current behavior
Any prompt, including trivial prompts in a newly created folder/workspace, enters:
and retries up to 5/5 without completing.
Earlier on the same machine, the same failure path also produced:
Why this report is separate from the Sep 26 outage
Related incident reports such as #48237 and #48306 indicate that the service-side issue was mitigated and that many affected users recovered without local changes.
My environment did not recover after that mitigation, and reinstalling the desktop app did not fix it.
Previous report: #48402
I am opening this as a fresh issue because the continuing post-mitigation behavior may be a separate or residual account/app problem rather than the already-mitigated outage.
Environment / checks already performed
codex login statusreports:Logged in using ChatGPTcodex-cli 0.101.0OPENAI_API_KEYis not defined in the Windows environmentnetstat -ano | findstr :17841showed no listener after the failed turn had endedSteps to reproduce
Reconnecting... waiting for networkattempts up to 5/5.Expected behavior
Codex should complete the prompt normally using the authenticated ChatGPT account.
Actual behavior
Codex remains stuck in the reconnect loop and is unusable on this PC even after the reported Sep 26 mitigation and after reinstalling the app.
Request
Could a maintainer please check whether there may be a residual account-side routing/auth/session issue, or advise which specific desktop logs / request IDs / diagnostics would be most useful to collect for this post-mitigation case?