[Withdrawn] Codex Desktop startup immediately triggers account-wide ChatGPT "Too many requests" restriction on Windows

Reporter update — withdrawn July 12, 2026: Subsequent investigation reproduced the same visible restriction through ChatGPT Classic's conversation-history flow. The current evidence therefore does not isolate Codex Desktop as the cause strongly enough to support this issue's original causal claim. I am withdrawing and closing this report rather than leaving a potentially misattributed Codex bug open.

What version of the Codex App are you using (From "About Codex" dialog)?

Codex App client version 26.707.31123; Microsoft Store package OpenAI.Codex 26.707.3563.0.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

Windows 11 Pro 25H2, build 26200.8655.

What issue are you seeing?

Starting Codex Desktop immediately triggers an account-wide ChatGPT conversation-access restriction, even before I submit a prompt or start a workspace task.

ChatGPT displays:

Too many requests. You're making requests too quickly. We've temporarily limited access to your conversations to protect your data. Please wait a few minutes before trying again.

The restriction is not confined to Codex or the Windows ChatGPT application. It appears in an already-open chatgpt.com session using the same account.

I performed a controlled isolation test:

• Fully quit both ChatGPT Classic and Codex, including their system-tray processes.
• Opened ChatGPT Web and submitted a prompt successfully.
• Kept ChatGPT Classic closed.
• Started Codex Desktop.
• The already-working ChatGPT Web session immediately displayed the restriction.

This means ChatGPT Classic, Windows UAC, WSL, Git activity, and a user-submitted Codex task are not required to trigger the problem.

Local Codex logs align with the reproduction:

• Codex processes started at approximately 2026-07-09 17:03:03 PDT.
• Codex recorded account/read at 17:03:35 PDT.
• Codex opened two authenticated warm-up WebSocket connections to wss://chatgpt.com/backend-api/codex/responses at 17:03:37-17:03:38 PDT.
• Both WebSocket handshakes succeeded using ChatGPT authentication.
• The local Codex logs did not record an HTTP 429 during this startup window.
• Cloudflare ray IDs from the two handshakes were a18b4e7078c8cb9a-LAX and a18b4e7218f52b72-LAX.

No active VPN or Windows system proxy was detected. Restarting and reinstalling the separate ChatGPT Classic application did not resolve the account restriction.

What steps can reproduce the bug?

1. Fully quit ChatGPT Classic and Codex, including system-tray processes.
2. Open https://chatgpt.com/ using the same ChatGPT account used by Codex.
3. Submit a prompt and confirm that ChatGPT Web responds normally.
4. Keep ChatGPT Classic closed and do not submit any additional web prompts.
5. Start Codex Desktop.
6. Do not start a Codex task or interact with a workspace.
7. Observe the already-open ChatGPT Web session.
8. ChatGPT Web immediately displays the "Too many requests" conversation restriction.

What is the expected behavior?

Starting Codex Desktop should authenticate and restore its UI without applying a conversation-access restriction to the same account in ChatGPT Web or ChatGPT Classic.

Normal Codex startup connections should not be classified as unusual or automated-looking account traffic, and Codex should not create duplicate account/session activity that triggers account-protection controls.

July 12 follow-up: downstream symptom clarification

Inspection of the currently served ChatGPT client clarified that the visible modal is emitted when the authenticated conversation-history request, GET /backend-api/conversations, receives HTTP 429.

This explains why the original Codex startup logs did not need to contain an HTTP 429: the user-visible restriction is a downstream ChatGPT history symptom. The Codex-specific question in this issue remains whether Codex startup and its authenticated warm-up activity contribute to the shared account-level rate-limit or abuse-protection bucket that subsequently causes the ChatGPT history request to be rejected.

A separate ChatGPT Classic deletion/refetch behavior was investigated but is intentionally omitted here because it is outside the scope of the openai/codex repository.

Additional information

Related issue: #27643 reports high CPU and possible ChatGPT rate-limit correlation during Windows/WSL startup. This report is materially different:

• No high-CPU symptom is required.
• No WSL workspace is required.
• No Git or workspace scan is required.
• No user-submitted Codex task is required.
• ChatGPT Classic remains closed.
• The controlled trigger is Codex startup itself, followed immediately by an account-wide restriction in a previously working ChatGPT Web session.

The \\wsl.localhost\... workspace workaround discussed in #27643 targets WSL/Git CPU behavior and does not address this isolated account/authentication startup reproduction.

I have not included account email, authentication tokens, cookies, complete logs, local usernames, or private conversation/workspace titles. OpenAI Support has the private incident report and can correlate the account using the timestamps and Cloudflare ray IDs above.