Three weeks of Codex Desktop hangs, timeout errors, instruction-following regressions and abnormal quota depletion — Pro user / Support Case #15362324

[asifu8866]

I am posting because I have an active OpenAI Support case and have been dealing with these problems for almost two and a half weeks. The problem remains unresolved while directly affecting time-critical production work immediately before G2E.

Active OpenAI Support Case: #15362324

I am a Codex Pro user and am currently preparing gaming products for G2E. Several game demos still need to be completed, alongside a substantial cabinet and platform migration.

Codex worked very well for me for months. That reliability is why I moved a substantial part of my development workflow onto it. The current problems began in early September 2026 and have continued for almost two and a half weeks.

I am not claiming that OpenAI is intentionally consuming my allowance, deliberately overcharging me, or that I know the technical root cause. I am asking OpenAI to investigate what is happening using the server-side session data already supplied through my Support case.

What changed

My underlying projects did not suddenly change, and my company is not an agency that abruptly added many unrelated customer projects. In fact, because of these problems, I substantially reduced the work assigned to Codex.

Claude now performs essentially all heavy coding and migration work. Codex primarily acts as the project manager:

1. Claude completes a coding or migration work order.
2. I manually copy Claude’s completion report into Codex.
3. Codex reconciles the report.
4. Codex updates its project-state records.
5. Codex records the completed work order.
6. Codex produces the next work order.
7. I manually copy that work order back to Claude.

I deliberately keep myself between the two systems rather than automatically connecting them because I am trying to control Codex usage.

Despite this reduced, manager-focused role, Codex frequently takes approximately 18, 20, 24, 28, or 29 minutes for what should be relatively lightweight reconciliation and prompt-generation work. Sometimes Claude completes the underlying coding task faster than Codex finishes recording the result and producing the next work order.

What I observe on Windows

On Windows, Codex can remain on Working or Thinking for 20–30 minutes during a relatively simple manager task. The interface may continue showing commands or activity, but the requested result does not visibly complete.

Eventually, I have to terminate Codex through Task Manager. After I reopen it, the completed response is frequently already present.

That creates a technical question I cannot answer from the client: if the useful response had already completed, what was happening during the remaining period before I terminated the application, and what usage was recorded during that period?

I am asking OpenAI to determine whether affected sessions were retrying model calls, reprocessing context, repeating tools, stuck in an agent loop, waiting on a broken stream, failing to recognize completion, continuing background work after useful completion, or experiencing client/backend state desynchronization. These are questions, not conclusions.

In another example, a manager session spent approximately 26 minutes on internal preflight and checkpoint activity, then acknowledged that no build, test, audit, or source edit had been performed. In one stuck session, roughly 30 minutes elapsed, but after restart the displayed completed work showed only approximately 1 minute and 44 seconds.

What I observe on macOS

The Mac symptoms are somewhat different. I have repeatedly experienced interface resets, blank screens, freezing, unresponsive sessions, long Thinking or Working states, forced quits, and submission failures.

I have reinstalled Codex multiple times, including twice in one day, without resolving the behavior.

A particularly important recurring Mac error is the red message:

Error submitting: timeout

I often see this after stopping a long-running or stuck operation and attempting to submit the next command.

I want engineering to determine whether the previous request remains active server-side, whether the client and backend lose synchronization, whether a request completed but the client failed to acknowledge it, whether retries continue, or whether stale or orphaned work remains active. Again, I am not asserting which explanation is correct.

Force-closing Codex during Unity work has disrupted the Unity process and caused loss of recent changes. A long-running Math Lab simulation also had hundreds of thousands of spins at risk because restarting it would mean restarting the batch. Even basic Mac file-management work, such as moving Unity builds to a USB drive, has required multiple force quits.

Usage discrepancy

My current Claude and Codex weekly periods reset approximately five to six hours apart. At my latest check:

• Claude: approximately 21% consumed
• Codex: approximately 55% consumed

Claude is performing substantially more of the actual heavy coding, while Codex is largely managing completed work.

I understand Claude and Codex meter usage differently, so this is not mathematical proof of incorrect Codex accounting. I am highlighting the discrepancy because it exists alongside repeated 20–30 minute abnormal Codex sessions and timeout failures.

Instruction-following and model quality

I have also recently observed deterioration in instruction-following and reasoning on lower Codex models. Examples include redoing work that was already finished, failing to follow explicit constraints, acknowledging a correction and then violating it, losing track of the current objective, and creating unnecessary correction loops.

Astra has been the most dependable model for some tasks, but it consumes allowance rapidly enough that I am reluctant to use it. This creates an operational choice between using the model that performs more reliably and worrying about exhausting the allowance, or using lighter models and spending more time and usage correcting or repeating work.

Existing public reports

There is relevant public context, although none of it proves that my account has the same root cause.

On September 9, OpenAI Status reported that some Codex users were experiencing unexpected usage-limit resets. OpenAI stated that it identified the issue, applied mitigation, and later marked the incident resolved: OpenAI Status — Investigating unexpected usage limit resets.

Recent reports in the official openai/codex repository include:

• Stuck task keeps consuming usage allowance with no output and cannot be stopped
• Direct user instructions are treated as optional, causing repeated failures, project risk, and additional usage
• Windows Desktop messages stop receiving replies and restarting Codex is required
• Codex Desktop tasks stuck on Thinking and stream disconnects across projects
• Something feels off with the usage limits
• One task reportedly processed approximately 242 million telemetry-reported tokens and consumed 11 percentage points of weekly quota
• Weekly quota reconciliation reported broken with no corresponding local activity
• Weekly quota oscillating between two reset windows

These are individual reports with different environments and triggers. They do not establish that my sessions share the same defect. They do establish a broader set of recent Codex reports involving similar classes of symptoms, which is why I am asking OpenAI to correlate my Support case and session data.

Support history and business impact

OpenAI Support already has multiple affected session IDs, screenshots, reset history, usage analytics, Windows and macOS examples, examples where the result appeared after restart, and almost two and a half weeks of correspondence.

A duplicate case, #15725567, was closed and redirected to the active case. I understand that it was closed because it duplicated Case #15362324, not because the technical complaint was rejected.

Support has repeatedly requested session IDs, timestamps, recordings, logs, and additional troubleshooting. I understand why diagnostics are useful, and I am willing to cooperate. However, I am days away from G2E and managing multiple development workstreams. I cannot become a full-time manual QA tester for Codex while trying to finish the product, especially when the relevant server-side session information exists at OpenAI.

Because of the instability, heavy coding was moved to Claude, additional money was spent with another AI provider, additional Codex credits were purchased, other projects were paused, and substantial development time has been lost. I am constantly monitoring usage and repeatedly restarting applications and machines. The ongoing situation is also creating significant stress and tension headaches.

What I am asking for

I am not asking the community to attack OpenAI or individual support employees. I am asking for:

• technical review of the affected sessions;
• an explanation of server-side model, tool, retry, and background activity during stuck states;
• clarification of what happens when the useful result exists after restart;
• investigation of timeout and client/backend synchronization failures;
• investigation of allowance consumed during malfunctioning sessions;
• appropriate remediation if malfunction-related usage is confirmed; and
• a stable product that can be relied on for production work.

If anyone from the Codex team sees this, the complete private evidence and affected session IDs are already attached to OpenAI Support Case #15362324. I would be grateful if engineering could correlate that case with these publicly reported failure patterns.