Issues with Codex – Identified – Full Outage

OpenAI confirmed a full outage affecting Codex, its cloud-based AI coding agent, with the incident logged on the company's status page under the designation 01M3DCNWMW57HYK8FJ5FBFPA39. The disruption rendered the service unavailable for users relying on Codex for automated coding tasks, pull request generation, and background agentic workflows. OpenAI moved the incident to the "Identified" stage, signaling that engineers had located the root cause even as remediation was still underway.

This piece breaks down what the Codex outage involved, how the service is architected in ways that make it susceptible to this kind of event, and what developers and engineering teams running Codex-dependent pipelines should know. If your team has wired Codex into CI/CD workflows or uses it to triage issues in background queues, the details here are directly relevant to how you build resilience into that stack.

01What actually changed

OpenAI's status page moved the Codex incident through the standard incident lifecycle, reaching the "Identified" phase after an initial period of investigation. At this stage, the engineering team had confirmed the underlying cause of the full-service disruption, stopping short of a full resolution. A full outage classification—as opposed to a partial degradation—means that the service was not processing requests at all during the affected window, rather than returning elevated error rates or degraded latency.

The incident record, carrying ID 01M3DCNWMW57HYK8FJ5FBFPA39, is publicly visible on OpenAI's status infrastructure. The company operates a dedicated status page that separates different product surfaces—ChatGPT, the API, and Codex each receive independent incident tracking. This outage applied specifically to Codex rather than the broader API, indicating the failure was isolated within the Codex service layer rather than the shared model inference layer that underlies most of OpenAI's products.

02How it works

Codex is OpenAI's agentic coding product, distinct from the Codex model that was historically offered through the completions API. The current Codex service operates as a cloud-side agent that can receive coding tasks, spin up sandboxed execution environments, write and run code, and produce pull requests or file changes asynchronously. Because this work happens in the background rather than in a synchronous chat loop, a full outage means jobs that were queued or mid-execution would have stalled without delivering results.

The "Identified" status indicates OpenAI's on-call team located the fault in the control plane or execution infrastructure before completing the fix. In distributed agentic systems like Codex, full outages typically trace to orchestration layers—job schedulers, sandbox provisioners, or internal routing services—rather than the model itself. Identifying the cause is a meaningful milestone because it constrains the blast radius of the investigation and lets engineering proceed directly to targeted remediation rather than broad rollback.

03Why it matters now

Codex has been positioned as a tool for engineering teams looking to offload well-defined coding tasks to an autonomous agent. Unlike a chat interface where a dropped connection is a minor inconvenience, Codex workflows are often asynchronous: a developer assigns a task, walks away, and expects a pull request or a code diff to appear. A full outage during that window means the task simply does not complete, with no output returned and no graceful degradation.

This pattern exposes a reliability dependency that teams may not have fully accounted for when integrating Codex into their pipelines. A chat-completion API call that fails can be retried in milliseconds.

An agentic coding task that fails mid-run may need to be re-specified, re-queued, and monitored again from scratch. The gap between uptime expectations for synchronous APIs and asynchronous agentic services is something engineering teams are navigating in real time as these products move from experimental to operational use.

04Who is affected

The outage affected users of OpenAI's Codex service directly—engineering teams and individual developers who had submitted coding tasks or were expecting completed outputs during the outage window. Organizations that have built internal tooling on top of Codex, such as automated issue-resolution bots, PR draft generators, or code review assistants, would have seen those integrations go dark for the duration.

API customers accessing Codex programmatically are also in scope. Any pipeline that triggers Codex jobs via the API and polls for results would have received errors or timeouts rather than completed work.

Teams using Codex through OpenAI's web interface would have seen similar failures. The scope of a full outage classification means there was no subset of users who remained unaffected—the service was unavailable across the board until OpenAI moved toward resolution.

05What to watch

OpenAI's status page will be the first place to confirm when the incident moves from "Identified" to "Resolved," and whether the resolution includes a post-mortem. For teams that run Codex in automated pipelines, the relevant follow-up question is what retry and fallback logic exists at the integration point. If a Codex job fails silently during a background run, developers need visibility into whether the task was dropped or queued for replay.

The incident is also worth tracking as a data point for teams evaluating agentic coding tools for production use. The reliability profile of asynchronous AI agents is still being established through real-world incidents like this one. OpenAI's handling of the post-incident report—particularly whether it describes the root cause and the architectural change made to prevent recurrence—will signal how mature the Codex operational model is relative to its API products.