Codex Desktop does not surface active service incidents or protect usage-heavy runs during known degradation

[grtninja]

Summary

Codex Desktop can continue a long-running, failure-prone agent session while the official OpenAI status page reports an active Codex/ChatGPT incident, without showing any in-product incident banner, affected-component notice, pause recommendation, or usage-protection path.

This report does not assert that the public incident caused every failure observed in the session. The narrower product defect is that current incident awareness is disconnected from the running Codex workspace, so a user can continue spending substantial included usage during known degradation without being told that service health may be affecting the run.

Environment

• Product: Codex Desktop
• Platform: Windows 11 Pro
• Subscription: ChatGPT Pro
• Workload: long-running repository coordination with repeated tool calls, GitHub operations, local integrations, and automatic context compaction
• Observed: July 23, 2026
• Official status at the time: active elevated-error-rate incident, mitigation applied and recovery being monitored

Steps to reproduce

1. Start or continue a long-running Codex Desktop agent task.
2. While the task is active, confirm that status.openai.com reports an incident affecting Codex, ChatGPT, or a component used by the task.
3. Return to the active Codex workspace.
4. Observe that no incident banner, affected-component warning, session annotation, or pause recommendation appears.
5. Allow the run to continue through failures, retries, reconnects, or compaction cycles.
6. Observe that normal usage continues to be consumed and the product offers no incident-linked review route.

Observed behavior

• The user must independently discover the status incident in a browser.
• The active Codex thread provides no authoritative notice that service health is degraded.
• A long autonomous run continues by default even when failures or retries are accumulating.
• Session telemetry visible to the user does not identify whether the run overlapped a known incident.
• There is no direct route to request review of usage spent during the incident window.

In the reporting session, the user was simultaneously investigating repeated context compaction and non-converging work. That compaction defect is separately tracked in #35032. The incident is included here for correlation only; causality is not established.

Expected behavior

When an official incident may affect the active Codex product path, Codex Desktop should:

1. show an in-product incident banner with the affected component and current status;
2. annotate active sessions with the incident window/identifier for later diagnostics;
3. warn before continuing a long or usage-heavy autonomous run;
4. offer a one-click pause and bounded handoff option;
5. detect repeated failures/retries during the incident and stop rather than silently burning usage;
6. provide a direct support/usage-review route tied to the affected session and incident window.

The application does not need to assume every error is caused by the incident. It does need to expose the known service condition and protect the user from continuing blindly.

Impact

• Users remain outside the operational information loop while the service already knows an incident exists.
• Paid/included usage may be consumed during runs that are less likely to converge.
• Diagnostics lose an important correlation signal.
• Users discover incidents through social posts, third-party sites, or manual status-page checks instead of the product they are actively using.

Related reports

• Codex Desktop auto-compaction completes but leaves long-running thread ~80% full, causing repeat compaction and usage waste #35032 — auto-compaction completes but leaves the thread about 80% full, causing repeat compaction and usage waste
• [Regression] Codex repeatedly reprocesses massive cached context in long sessions, causing severe latency, timeouts, JSONL growth, and excessive credit usage #34971 — repeated cached-context reprocessing, latency, timeouts, and excessive credit usage
• Codex enters self-reinforcing governance loops, ignores bounded scope, and exhausts usage without completing tasks #34898 — self-reinforcing governance loops and quota exhaustion without task completion

This issue is specifically about in-product incident visibility, run protection, and session-linked usage review during a known service degradation window.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

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

Powered by Codex Action

[koko3tallah]

One implementation detail that would keep this from becoming a noisy provider-wide kill switch: evaluate the status of the product path the run is actually using, then combine that external signal with the local failure budget proposed in the issue.

A concrete state machine could be:

1. Fetch a service-scoped status snapshot on session start and periodically with a short cache. A fetch failure should preserve the last-known value briefly and otherwise fail open.
2. degraded for the applicable service -> show a non-blocking, timestamped banner and checkpoint the run.
3. outage for the applicable service plus a bounded local threshold (retryable errors, repeated reconnects/compactions, or no checkpoint progress) -> pause autonomous continuation and offer continue, pause, or bounded handoff.
4. Persist only the service slug, status-source timestamp, incident identifier when available, and overlap window with the session. That is enough for later support correlation without claiming causality.

The service scope matters. A current normalized snapshot, for example, reports ChatGPT as degraded while the OpenAI API is operational; a single provider boolean would incorrectly pause API-only work. Public, keyless JSON examples:

• provider/service inventory: https://outagedeck.com/api/v1/providers/openai
• ChatGPT path: https://outagedeck.com/api/v1/services/chatgpt
• API path: https://outagedeck.com/api/v1/services/openai-api
• response model and usage notes: https://outagedeck.com/developers/api?utm_source=github&utm_medium=issue&utm_campaign=codex_incident_protection

For Codex itself, the product should still map its internal lane/component identifiers to the exact official OpenAI status component whenever that data is available; the normalized endpoints above are an implementation example and fallback/correlation source, not a reason to replace the first-party signal.

Disclosure: I build OutageDeck. I am sharing the endpoints because this issue is the exact failure mode the read-only status API is designed to support; there is no key or account required for these checks.