Persistent Codex/Work instability since Sep 24 across Desktop and Web, with unexplained usage #52884

Summary

I am a ChatGPT Plus user reporting a persistent Codex / ChatGPT Work reliability problem that began on September 24, 2026 and has remained unresolved across both:

• Codex Desktop on macOS
• ChatGPT Work / Codex on the web

This is not a report about one long conversation or one isolated failed task. The failures have occurred across multiple separate conversations, including newly created / low-context conversations.

I am not asserting a root cause. I am asking OpenAI to correlate the existing diagnostics and determine whether this is a client, account/session, cloud-task recovery, streaming/session, usage-accounting, or other service-side issue.

The primary impact is that Codex / Work is not reliable enough for normal paid production use.

The usage observation described below is not the primary complaint. It is relevant because, while the underlying Codex/Work reliability problem remains unresolved, I cannot reliably distinguish normal intentional usage from usage associated with failed requests, retries, background/cloud activity, interrupted tasks, or accounting delay.

Impact

Since Sep 24, I have repeatedly had to abandon or recreate Work/Codex conversations because an existing conversation became unusable.

Observed effects include:

• work interrupted after substantial progress;
• conversations becoming inaccessible;
• cloud tasks appearing to continue while the front-end stream/conversation becomes unavailable;
• repeated retries / reconnects;
• inability to know whether usage consumed during failure periods represents normal model work or failed/background activity.

My first priority is restoring stable Codex / Work operation.

Usage correction is secondary and should be reviewed after the underlying service problem is understood.

Timeline

All times below are UTC+8 unless otherwise stated.

Sep 24, 2026 — Codex Desktop failures begin

The same Codex Desktop workflow/setup had been working normally before this date.

Beginning Sep 24, multiple separate Codex Desktop conversations started showing failures including:

• {"detail":"Bad Request"}
• Reconnecting 5/5

Important observations:

• failures occurred in multiple short/new conversations, not only in a long-context thread;
• in one conversation, even simple text messages produced three consecutive Bad Request failures;
• one affected conversation later recovered temporarily, then failed again while Codex was still processing, without a new user message causing the transition;
• quitting and reopening Codex Desktop did not reliably resolve the issue.

Sep 24–25 — Diagnostics captured

I captured and submitted:

• Codex Desktop logs covering Sep 24–25;
• a Codex feedback/session identifier;
• exact affected conversation identifiers;
• screenshots and timestamps.

I am intentionally not posting raw logs, conversation UUIDs, support-case identifiers, account information, or local user paths publicly. These can be provided privately to OpenAI maintainers for correlation.

After approximately Sep 26 — Desktop largely removed from the workflow

After the Desktop failures, I stopped intentionally running Codex Desktop production tasks and moved primarily to Work/Codex on the web.

This matters because later failures were not limited to the original Desktop environment.

Oct 3, 2026 ~02:07 — Fresh Work web conversation fails

A newly created Work web conversation with very little context failed with:

• Could not load this ChatGPT conversation

This was not a large legacy thread and did not require a complex external workload before the failure appeared.

Subsequent Work web failures

Across separate Work conversations I observed combinations of:

• Could not load this ChatGPT conversation
• Unable to send this ChatGPT message
• Unable to check locked mode
• A network error occurred. Please check your connection and try again.
• Resume stream unavailable
• connection interruption while waiting for a complete response
• conversation becoming inaccessible while cloud work appeared to remain active

Standard ChatGPT remained usable during at least some of the same periods when Work/Codex was failing.

Oct 7, 2026 ~22:56 — Cloud Work reaches 99%, then disconnects

A Work task running in the cloud reached 99% and then the conversation showed a connection interruption / waiting-for-complete-response state.

The task had already performed substantial work before the stream/session failed.

Oct 8, 2026 ~00:42–00:48 — Temporary recovery, then another stream failure

The same general Work session recovered temporarily and became usable again, then failed again with:

• Error in message stream

My last known intentional ChatGPT / Work activity before the later usage observation was approximately Oct 8 around 00:48 UTC+8.

Oct 10, 2026 ~20:31 — Usage present before any new task/message

This is the clearest usage-related observation.

Before this moment:

• the Mac had been powered off for approximately 2+ days;
• I had not been using Codex Desktop or ChatGPT Work;
• I had not opened ChatGPT on the web;
• when I powered on the Mac, I had not opened Chrome yet;
• I had not sent any Codex message;
• I had not started any Codex/Work task;
• I do not use this OpenAI account on another device during this period.

I opened Codex Desktop only to check the allowance/reset time.

Before sending any message or starting any task, the UI showed:

• 5-hour allowance: 98% remaining (2% used)
• approximately 01:06 remaining until reset in the captured screenshot

OpenAI support later confirmed that the screenshot matched the account-side state they could see and also stated that simply launching Codex Desktop is not expected to start a new five-hour window.

Support suggested possible explanations such as prior usage already counted in the window, a cloud/background task continuing or retrying, or reporting/accounting delay, but email support stated that it could not access the per-event ledger needed to identify the exact event.

I am not claiming which explanation is correct.

I am asking for the exact account/service-side event to be correlated with this observation.

Expected behavior

1. Codex / Work conversations should remain accessible while a task is running and after it completes.
2. A transient stream failure should not make an in-progress or completed cloud task effectively unreachable.
3. New/short conversations should not repeatedly fail with Bad Request, reconnect exhaustion, or conversation-load errors.
4. If a Work/Codex task continues in the cloud after the front-end connection is lost, the UI should reliably recover the task state and provide a clear stop/control path.
5. Work/Codex usage should be attributable to understandable user-initiated or documented background activity.
6. Merely opening Codex Desktop before sending the first message should not itself create unexplained usage.

Actual behavior

The failure mode is intermittent and can temporarily recover, then return.

Across Desktop and web I have observed:

• request rejection (Bad Request);
• repeated reconnect exhaustion;
• conversation-load failure;
• unrecoverable / unavailable response streams;
• Work cloud execution progressing while the conversation UI becomes disconnected or inaccessible;
• temporary recovery followed by another failure;
• unexplained Work/Codex usage present before a new user message/task after a long inactive period.

This combination makes it difficult to determine whether a failed UI/session represents:

• a client-only stream failure;
• a server-side conversation/session problem;
• an orphaned/retrying cloud task;
• delayed usage reporting;
• or another backend state issue.

Important controls / observations

These points are included to avoid repeating explanations that do not fit all observed cases:

• The failures are not limited to one long conversation.
• At least one failure occurred in a new / very low-context Work conversation.
• The problem is not limited to Codex Desktop; it also occurred in Work on the web.
• After approximately Sep 26, I was no longer intentionally running Desktop Codex production tasks, yet web Work failures continued.
• Some failures occurred after a task had already made substantial cloud progress.
• Standard ChatGPT remained usable during some Work/Codex failures.
• The Oct 10 usage observation occurred before Chrome was opened and before any new Codex message/task was started.
• I am not claiming that all of these symptoms necessarily have one root cause; I am asking OpenAI to correlate them.

Diagnostics already available to OpenAI

I have already collected/submitted:

• Codex Desktop logs for Sep 24–25;
• exact affected Desktop conversation IDs;
• exact affected Work web conversation IDs;
• a Codex feedback/session ID;
• screenshots of the error states;
• timestamps for the failures;
• the Oct 10 usage screenshot.

For privacy/security, I am not publishing those unique identifiers or raw logs in this public issue.

I can provide them privately to an OpenAI maintainer/engineer who can correlate them with backend telemetry.

Possibly related public reports

I am not claiming these issues have the same root cause. These are included only because parts of their observed symptoms overlap:

• [ChatGPT Web/Android][Sep 24–26, 2026] Frequent conversation load failures, 429 errors, and delayed image attachments #48393 — ChatGPT Web/Android: intermittent conversation-load failures and 429-style errors during Sep 24–26
• [Windows] Existing chats intermittently show "Couldn't load this ChatGPT conversation" #50000 — Codex Desktop: existing conversations intermittently fail to load while Work may still appear active
• ChatGPT Work web: interrupted stream stays stale while new progress persists; follow-up disappears after reload #51973 — ChatGPT Work web: the visible stream becomes interrupted/stale while newer task progress can continue to persist
• {"detail":"Bad Request"} on every turn + failed remote compact for one thread; other threads unaffected #52320 — Codex Desktop: repeated Reconnecting 5/5 followed by {"detail":"Bad Request"} for an affected thread

Please correlate rather than assuming they are identical or share one root cause.

What I am asking OpenAI to investigate

The primary issue is the unresolved Codex/Work reliability failure. The usage observation is supporting evidence and a secondary account-integrity concern, not the main complaint.

Priority 1 — Restore reliable Codex / Work operation

Please determine why the same paid account has experienced repeated Codex/Work failures across Desktop and web since Sep 24 and provide a fix or mitigation that restores reliable operation.

Priority 2 — Stop unexplained usage while the service is unstable

Please determine whether failed/retrying/background/cloud/session-recovery activity is consuming Work/Codex allowance in ways that are not visible or controllable from the user-facing UI.

For the Oct 10 observation in particular, please identify internally:

• what event started or belonged to the active 5-hour window;
• the timestamp of the relevant usage event(s);
• associated task/conversation/session, if any;
• whether the activity was user-initiated, cloud/background, retry/recovery, delayed accounting, or another system event.

Priority 3 — Review affected usage after the service issue is understood

After the underlying reliability issue is identified/stabilized, please review usage during the affected period beginning Sep 24 and restore/credit usage that can be verified as abnormal, duplicated, caused by failed/retrying/background service activity, or otherwise not attributable to normal intentional work.

Privacy note

I deliberately removed from this public report:

• account email/name;
• support ticket numbers;
• conversation UUIDs / direct conversation URLs;
• feedback/session UUID;
• device identifiers;
• IP/network/location information;
• local username/file paths;
• authentication information;
• raw log files.

Those identifiers are available privately for OpenAI maintainers if needed for backend correlation.

Requested maintainer action

Please do not close this only as generic network troubleshooting without correlating the existing server/account-side diagnostics.

The key question is not whether a single WebSocket can disconnect. The issue is the repeated combination of request rejection, conversation/session loss, cloud-task recovery problems, and unexplained usage across multiple Work/Codex surfaces over more than two weeks.

I can provide the private identifiers/log bundle directly to an OpenAI maintainer if there is a safe/private channel for correlation.