Codex Continues to Fail on June 25: What Really Happens Is a One-time Failure or a Chronic Quotas Problem
Main chat
A chat for vibe coders: news, guides, live cases, marketplace, and finding executors.
If June 23 looked like a regular, albeit noticeable failure, by June 25 the picture became more complicated. The official Codex status page shows a warning icon for all five components of the service - Codex Web, App, Codex API, CLI and extensions for VS Code. At the same time, independent trackers at the same time give contradictory readings: one fixes a partial failure with problems in several components, the other in the same morning reports that there were no reports over the past day at all.
Let’s look at what’s behind this discrepancy and why what’s happening is more like not just one isolated incident, but an ongoing problem that’s been going on for weeks.
What is officially confirmed: chronology by OpenAI status
According to the official OpenAI status page, several separate records of service degradation were recorded on June 23.
At 14:27 ET, the post “Users may experience an increased number of errors when downloading and downloading files in ChatGPT” appeared – the incident lasted 2 hours and 15 minutes, after which it was noted as completely eliminated.
In parallel, a longer degradation continued from the early morning of the same day—“FedRAMP and API workspaces are experiencing reduced performance”—with a duration of 13 hours and 20 minutes. FedRAMP is a certified infrastructure for U.S. government and regulatory organizations, separate from ChatGPT’s core consumer infrastructure.
The independent tracker StatusGator, which monitors its own data in addition to the official OpenAI, recorded a Warning status on the Codex component throughout the day on June 23 – and this status continued the next day, June 24, for more than 10 hours.
What users saw: data from DownDetector and forums
It’s worth separating officially confirmed facts from community observations — two different, if related, sources of information.
According to the tracker DownDetector, the volume of user reports began to grow sharply at about 9:21 am ET on June 23, a spike recorded by independent community sites that track the status of ChatGPT and Codex in real time.
On the OpenAI Community developer forum, complaints typical of such incidents appeared: errors in the execution of tasks in the Codex cloud, suspended sessions, failure to receive a response from the model when trying to run an agent task through the command line interface. Such discussions typically accompany any disruption of this magnitude and usually provide a more lively, if less structured, picture of what is happening than official status updates.
Bug tracker: 7,378 open issues and what they really write
Much more indicative of the official status is the open task tracker on GitHub, where Codex developers display bug reports directly from users. At the time of writing, there are 7,378 open and 8,803 closed calls — a counter that is growing almost continuously, with dozens of new tickets every day, including many opened on June 25.
Among the latest tickets are problems of a very different nature: hanging command line sessions after processing the request, re-starting the installation of an isolated environment on Windows when changing the proxy settings, breaking the connection with daughter agents in subagent scenarios, failure to record sound on macOS when switching audio streams, missing modules when installing Codex sandbox on Windows.
But one ticket stands out especially - the headline "Quota exhausted instantly: 100 credits gone after 1 post, 5-hour limit reset to 0%" garnered 13 comments, which is a lot for one individual bug report. This is not an isolated complaint - similar reports of abrupt and disproportionate spending of quotas have been occurring on the tracker regularly over the past weeks, not just today.
The real cause of noise is not a one-off failure, but a problem with the quota flow metric
Compared with the story of the past month, a more accurate picture emerges: what looks like the June 25 glitch is actually a continuation of the problem that users have been documenting since early to mid-May 2026.
Back in May, the OpenAI developer forum featured a theme titled “Codex users report rapid quota consumption starting on May 10,” describing a situation in which limits were exhausted in just an hour of easy use with younger models of the line. Later, similar complaints appeared on GitHub: one of the tickets describes the situation on the Pro 5x tariff, where the weekly limit fell sharply after June 1, and the quota continued to be spent even during periods when Codex was not actively used. Another recorded case was that a minimal one-line configuration change ate about 2% of the five-hour limit, which is clearly not proportional to the amount of work done.
That is, the complaint with 13 comments on the screenshot is not an isolated episode on June 25, but part of a consistent pattern: Codex’s quota consumption metric periodically fails, causing users to lose access much faster than they should at their actual usage volume. The difference between “service is unavailable” and “service is working but miscalculating resources” is fundamental – these are two different types of problems that look equally annoying from the outside, but require different solutions from OpenAI engineers.
Important caveat: Don't be confused with April crash
When looking for information about the Codex and ChatGPT crashes, it’s easy to come across articles about a much larger incident – the one that occurred on April 20, 2026. These are two different events and should be clearly distinguished.
The April glitch was significantly larger: Reports rose from a few hundred to more than 5,000 in about 30 minutes, with peak estimates above 8,000, according to DownDetector. The UK received more than 7,600 reports versus about 1,700 in the US, indicating a problem localized to a specific infrastructure region. Then affected not only Codex, but also the basic entrance to ChatGPT, voice mode and API Platform as a whole, and recovery took about an hour and a half with uneven return of access for different users.
The June 23 crash, according to officially confirmed data, is noticeably narrower in scope: specifically downloading/downloading files and degradation of the dedicated FedRAMP loop, rather than the complete inaccessibility of all major functions at once. If there are 5,000+ or 8,000+ reports and a discrepancy between the U.K. and the U.S., this is likely a description of the April incident, not the June one.
This is not the first or the last time: statistics on the frequency of failures
A useful context for assessing the scale of anxiety: Codex incidents like this are not uncommon. In the past two months alone, independent monitoring by StatusGator has recorded dozens of individual warnings of varying durations, ranging from a few minutes to a day of continuous degradation, including episodes on May 7-8, May 11-13, May 22-23, May 27-28, June 2-3 and lasting virtually the entire last week of June.
Some of these warnings are not related to a complete drop in the service, but to narrower problems – for example, the “Selected Model is at Capacity” error, which indicates not a complete infrastructure failure, but the exhaustion of power for a particular model at peak load times.
This is consistent with the overall picture: and independent reviews note that OpenAI’s infrastructure is under constant pressure from growing demand, with a historical frequency of 2-3 notable incidents per month.
Why Codex is especially sensitive to such failures
An important feature of Codex (as opposed to the usual dialogue in ChatGPT) is an agent tool that performs multi-step tasks, often lasting minutes or hours. If a failure occurs in the middle of a long agent session — for example, a mission that has to code, run tests, and make commits for an hour — a connection break or server error can leave a task in an uncertain, partially executed state that is harder to recover than just repeating a single failed chat request.
This explains why Codex failures—unlike those of conventional ChatGPT—are particularly acute among developers: Losing context in the middle of a multi-hour standalone task costs more in time than losing a single unsent message.
How to Minimize Risk in Your Work Process
There are several practical measures that reduce reliance on the stability of a particular provider, regardless of when the next failure occurs.
** Check status before the long task begins.** The official status.openai.com page is updated in real time and shows degradation by specific components – Codex CLI, Codex API, Codex Web – separately from each other. Before starting a multi-hour autonomous task, it is wise to look there.
**Do not run critical long-term tasks without save points. If your workflow involves a long standalone session, make sure that intermediate progress is recorded (committees, checkpoints), and not lost entirely when the connection breaks.
** Have an alternate path to another model or provider. If your workflow is rigidly built around a single tool without the ability to switch, any failure of that tool stops you from working. Putting a backup option (another model, another agent) is not paranoia, but normal engineering practice with the current frequency of such incidents at all major providers without exception, including Anthropic and Google.
Subscribe to status notifications rather than manually checking. The OpenAI status page supports email or RSS update subscriptions, which is faster than updating your browser tab periodically to see if you have a problem locally or everyone else.
Outcome
According to officially confirmed data, the failure on June 23, 2026 is two separate, not the largest by historical standards of the incident: a two-hour problem with downloading files in ChatGPT and a longer degradation of the dedicated FedRAMP-contour. Independent trackers additionally record the growth of user reports starting in the morning of the same day, which corresponds to users’ feelings about “today everything broke”, even if in fact the incident did not reach the scale of more serious failures of past months.
The very frequency of such incidents is not a one-time anomaly, but part of the current reality of working with cloud AI services at the limit of demand. From this follows a practical conclusion not for a particular day, but for the work process as a whole: laying the resistance to failures of the provider is a reasonable habit, not excessive reinsurance.
*This article is based on the official status history of OpenAI (status.openai.com/history), independent monitoring by StatusGator and EagleStatus, as well as user posts on DownDetector and the OpenAI Developer Community forum. Current on June 24, 2026; if there is additional official confirmation of the cause of the failure, the article will be supplemented. *
