Codex Desktop does not surface active OpenAI incidents or pause failure-prone long-running sessions

Summary

During a long-running Codex Desktop repository session on Windows 11, the official OpenAI status page showed an active Elevated Error Rates incident that had been ongoing for several hours. The running Codex session displayed no in-product incident warning, no degraded-service indicator, no recommendation to pause, and no usage-protection or review route.

The session continued through repeated context compaction, repeated planning/tool activity, and rapid included-usage depletion while production progress remained stalled.

This report does not assert that the public incident caused the separate compaction defect reported in #35032. The narrower defect is that Codex Desktop had access to no visible service-health signal or protective behavior during a known public degradation window.

Environment

• Product: Codex Desktop
• Platform: Windows 11 Pro
• Subscription: ChatGPT Pro
• Workload: long-running tool-heavy repository coordination
• Observed: July 23, 2026
• Codex Desktop version: not captured in the screenshots used for this report
• Related report: #35032

Observed behavior

1. A long-running Codex task was active and consuming included usage.
2. The task was already exhibiting repeated compaction/reprocessing and poor convergence.
3. The official OpenAI status page showed an active Elevated Error Rates incident and stated that mitigation had been applied while recovery was being monitored.
4. Codex Desktop did not display an incident banner or degraded-service state in the active thread.
5. The agent continued operating and consuming usage until the account was nearly exhausted.
6. The user discovered the incident only by manually opening the external status page.

Expected behavior

When an official incident affects a service or component relevant to the active Codex lane, the app should:

• show a clear, timestamped in-product incident indicator;
• state which Codex/model/tool surfaces may be affected;
• distinguish confirmed impact from possible correlation;
• preserve the current task checkpoint;
• offer continue, pause, or create bounded handoff choices;
• automatically stop or require confirmation after repeated transient failures or non-progress loops;
• avoid blindly replaying completed tool calls after recovery;
• expose the appropriate route for reviewing usage consumed during the affected session.

Suggested circuit breaker

A running session should enter a visible degraded state when both conditions hold:

1. an applicable official incident is active; and
2. the session crosses a bounded threshold of retryable failures, repeated tool calls, repeated compactions, or failure to advance its execution checkpoint.

The app should then stop autonomous continuation, persist a compact handoff, and require an explicit user decision before consuming more usage.

Why this is separate from #35032

#35032 concerns the measurable compaction outcome: auto-compaction reports success but immediately leaves the thread around 80% full.

This issue concerns incident observability and user protection: the official service was publicly degraded, but the active Codex session provided no warning or protective state transition.

Impact

• Users continue spending included or purchased usage during known degraded-service periods.
• Failures look like project/configuration problems rather than service degradation.
• Users must discover incidents through external pages or social channels.
• Long-running tasks can compound the damage through retries, compaction, and duplicated work.

Screenshots of the active Codex session, usage state, and official status page are available. Private repository names and paths are omitted from this public report.