Windows Codex Desktop: HTTP 429 across multiple tasks while ~70% of weekly allowance remains #53978

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

26.1007.21434 — last observed in local desktop logs on October 13, 2026; not rechecked in About for every October 14 failure.

What subscription do you have?

ChatGPT subscription; account usage response reports planType: prolite.

What platform is your computer?

Windows (Codex desktop app).

What issue are you seeing?

Summary

On October 14, 2026 (Asia/Shanghai, UTC+8), I encountered HTTP 429 errors in multiple different tasks in the Windows Codex desktop app. The problem is not confined to the original long conversation.

When account usage was queried during troubleshooting, the weekly allowance showed 30% used (approximately 70% remaining), and ordinaryUsageAllowed was true. This is not evidence that all rate limits were clear: other short-term or service-side limits may still apply. The UI did not explain which limit caused this rejection.

Environment

• Product: Codex desktop app on Windows, signed in with a ChatGPT account.
• Last locally observed desktop release: 26.1007.21434 (from October 13 logs; not independently rechecked for every October 14 failure).
• Model observed in the affected task's connection-error logs: gpt-6-astra, medium reasoning. The model has not been verified for every task that returned 429.
• Date of the cross-task 429 reports: October 14, 2026, UTC+8.

Error evidence

The screenshot shows:

exceeded retry limit, last status: 429 Too Many Requests, request id: 0337d3e0-508f-4957-b3fe-5fb57422af83

The UI also shows “已处理 6分钟47秒” (processed for 6 minutes 47 seconds) and “服务器繁忙，正在重新连接 1/5” (server busy, reconnecting 1/5). The screenshot does not provide an exact wall-clock time.

The account usage query returned:

• Weekly window: 10080 minutes.
• usedPercent: 30 (about 70% remaining).
• ordinaryUsageAllowed: true.
• rateLimitReachedType: null.
• spendControlReached: false.
• No secondary window was returned by this query. This should not be read as proof that no other limit exists.

What steps can reproduce the bug?

Observed behavior / reproduction limits

1. Use existing tasks in Windows Codex Desktop.
2. Some turns stall and display connection/retry messages.
3. Multiple different tasks returned HTTP 429 on the same day.
4. Checking account usage still showed approximately 70% of the weekly allowance available.

This is a report of observed intermittent behavior, not a deterministic minimal reproduction. I have captured the request ID above; request IDs from all the other affected tasks have not yet been collected.

What is the expected behavior?

Expected behavior / requested investigation

• Please correlate the request ID with backend logs and identify the specific limit or service condition responsible.
• If this is a short-term rate limit, show the affected limit and an actionable retry time, distinguishing it from exhausted weekly allowance.
• If it is a service-side issue, please confirm and track it.
• Please clarify why the UI shows both “server busy” and “exceeded retry limit” without identifying the applicable limit.

Additional information

Related connection failures

During this troubleshooting period, the app also displayed:

stream disconnected before completion: websocket closed by server before response.completed
stream disconnected before completion: IO error: 远程主机强迫关闭了一个现有的连接。 (os error 10054)

Local logs recorded WebSocket retries followed by HTTP fallback. A fresh conversation initially worked, but failures later recurred. I cannot establish that the connection failures and the 429s share one root cause, or that conversation length caused the 429s. Cross-network comparison and request concurrency have not been controlled.

Related reports and support history

• HTTP 429 is surfaced as "exceeded retry limit" without retrying; expose retry_429 or clarify error #30471 discusses the same 429 error wording; this report concerns observed cross-task failures with weekly allowance still remaining, not a claim that the source-level issue proves our root cause.
• Frequent reconnect loop in Codex App: websocket closed by server before response.completed #18960 contains similar WebSocket reconnect reports.
• I submitted this evidence to the OpenAI Help Center support conversation. Its AI support confirmed the message was recorded but said it could not query backend logs, confirm engineering acceptance, or transfer the conversation to human support. No engineering ticket number has been provided.

No email address, account ID, private task IDs, project names, local file paths, creative content, or full logs are included in this public report.