Repository navigation
[Windows] Existing chats intermittently show "Couldn't load this ChatGPT conversation" #50000
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.928.3736.0
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26300.0 x64
What issue are you seeing?
Existing conversations in the Windows desktop app intermittently fail to open with "Couldn't load this ChatGPT conversation" / "Couldn't load conversation" and a "Try again" button.
The affected conversations vary between launches. Sometimes only a few fail; at other times many or nearly all existing chats fail while some still load normally on the same PC and connection. In some cases a conversation briefly flashes its content for a fraction of a second and then returns to the loading error.
Work chats can continue showing a spinning/running indicator while the conversation itself is inaccessible, so I cannot monitor or interact with the running task. "Try again" often does nothing. Some affected chats later recover without any network or system change, then can fail again on a later launch.
The issue recurred repeatedly from the evening of September 30 into October 1, 2026 (EDT). General internet connectivity remained normal. The pattern appears consistent with an intermittent desktop-client/backend conversation retrieval or session-sync failure rather than deleted conversations or a general network outage.
What steps can reproduce the bug?
Feedback ID: no-active-thread-01a0f5e9-0703-7de3-be12-c059d7743948
- Open the ChatGPT Windows desktop app and sign in.
- Open an existing conversation from the sidebar.
- An affected conversation shows "Couldn't load this ChatGPT conversation" / "Couldn't load conversation" with a "Try again" button.
- Click "Try again", reopen the conversation, or relaunch the app. The same chat often still fails; sometimes its content flashes briefly and then returns to the error.
- Open other existing chats. Some may load normally while others fail, and the affected set can change between app launches.
- For an affected Work chat, the running/spinning indicator may remain visible even though the conversation cannot be opened or monitored.
- Without changing the network or system, a failed chat may later recover, then fail again on a later launch.
What is the expected behavior?
Existing saved conversations should load reliably in the Windows desktop app. If a transient retrieval error occurs, "Try again" should reload the conversation. Running Work conversations should remain accessible so their progress can be monitored and interacted with.
Additional information
Environment:
- ChatGPT/Codex Microsoft Store package: 26.928.3736.0
- Desktop renderer release: 26.928.31416
- Codex CLI/app-server: 0.159.2
- Subscription: ChatGPT Plus
- Windows 11 Home 26H2, build 26300.9550, x64
- Exact platform string: Microsoft Windows NT 10.0.26300.0 x64
- Reproduced repeatedly from the evening of September 30 into October 1, 2026 (EDT)
Troubleshooting already performed:
- Closed and reopened the desktop app, including force-ending/relaunching it
- Signed out and back in
- Used "Try again" / refresh repeatedly
- Tested the web version and a private/incognito browser window
- Compared behavior across chats and devices
- Installed the latest available Windows desktop app update
- Installed Windows updates and restarted Windows, including a full PC restart
- Confirmed other internet access was working normally
Some conversations that failed on the Windows desktop app were accessible on another device, and some failed desktop conversations later recovered without any local network or system change.
Activity
github-actions commentedon Oct 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
oc12121212 commentedon Oct 1, 2026
Possible related issue: #45912. The core symptom is very similar: existing conversations fail to load in the Windows desktop app while other chats/devices may still work.
This report reproduces the problem on the newer Windows package 26.928.3736.0. In my case, the affected conversations can change between app launches, previously failing conversations can recover without any network/system change and later fail again, and Work chats can remain actively running while their conversation becomes inaccessible in the desktop app.
I included the feedback ID generated by Send Feedback in the issue body for correlation.
oc12121212 commentedon Oct 1, 2026
Additional diagnostics from 2026-10-01 on Windows package
OpenAI.Codex 26.928.3736.0:GET /conversations/{conversation_id}?num_turns=10&include_has_versions=truewith{"detail":"Too many requests"}.chatgpt_completion_transport_recovery_poll_failedloop. The log showed attempts 26 through 32, roughly 10 seconds apart, with each conversation GET returning 429.Failed to refetch ChatGPT conversation after an update(reason=explicit_update) after the same 429 response./conversations/{conversation_id}429 through the next validation point.Current working hypothesis: desktop refetch/recovery behavior can amplify
/conversationstraffic enough to hit the conversation-history protection/rate limit; once that happens, existing-chat loading surfaces as "Couldn't load this ChatGPT conversation." The current workaround is to stop rapid navigation, allow a cooldown, then open chats one at a time. This is not a permanent fix.It may be worth adding bounded backoff/abort behavior to recovery polling and preventing overlapping conversation refetches after 429s.
oc12121212 commentedon Oct 1, 2026
Additional reproduction from Oct 1 2026:
I reproduced the load failure again without pressing Try again.
After a cooldown, opening one existing conversation succeeded normally and generated no new HTTP 429s or recovery poll failures. I then opened several other existing conversations sequentially. The Windows app returned three fresh HTTP 429 responses on GET /conversations/<conversation_id>, about three seconds apart, and the UI showed Could not load this ChatGPT conversation with the Try again button.
I did not press Try again during this reproduction.
After navigation stopped, a passive 35 second observation period produced zero new 429s and zero new recovery poll failures.
This strengthens the earlier observation that repeated manual retries are not required. Conversation retrieval or navigation itself can enter the 429 state. Once navigation stopped, the burst stopped as well. Earlier logs still separately show the automatic recovery loop after a conversation has entered the failed state.
oc12121212 commentedon Oct 1, 2026
Additional verified trigger from Oct 1, 2026:
Too many requests) responses toGET /conversations/{conversation_id}?num_turns=10&include_has_versions=truebetween23:21:07.395Zand23:21:07.861Z— about 466 ms total.This identifies Activity-view population itself as a request fan-out trigger. A safe local mitigation is to keep Activity view closed and avoid rapid/batch conversation navigation while this issue is present.
dheeraj5612 commentedon Oct 10, 2026
Additional macOS reproduction with actual console and desktop-log evidence, observed October 9, 2026 around 22:51–23:07 EDT (October 10, 02:51–03:07 UTC).
Environment: desktop app 26.1002.52244, build 13536, bundle com.openai.codex; Darwin 27.0.0, arm64. Research uses Pro; the exact billing tier was not independently inspected.
Reproduction:
Could not load this ChatGPT conversation.Try againonce. The same error remains.Affected saved chat: https://chatgpt.com/c/6ac825b3-ab1c-8329-852a-5e341305fb1f
The full existing response was successfully copied earlier in this session, so this is intermittent retrieval failure, not evidence that its stored content is absent. Its downloadable workbook becomes inaccessible while the conversation fails. Other conversations recovered without a reset.
Two desktop tool operations also returned the exact result
{"detail":"Too many requests"}: navigation to this conversation and reading https://chatgpt.com/c/6ac8198a-490c-8325-9e40-84a83690305f . The tool responses themselves did not expose HTTP statuses; the HTTP 429 above was independently observed in Edge's console.The original project still has visibly running work. A read tool returning only the user prompt did not prove generation failure: the desktop UI showed research progress and a Stop button. Recovery should preserve and reconnect to active work, rather than silently duplicate it.
Separately, actual desktop
thread/readlogs contain placement-decoding errors and backend request IDs. These are not asserted to be the cause of the HTTP 429s; placement-v3 evidence is tracked separately in #51731. Edge also logged a CSP-blocked inline script at the platform runner, but its causal relationship is unconfirmed.In-app feedback submitted: 5c5fa812-2f0a-4289-823f-7b4522b4f115. The local log recorded successful completion of
feedback/uploadat 2026-10-10T03:03:55.729Z (errorCode=null). Current-conversation diagnostic logs were included; unrelated browser tabs/logs were excluded.Please investigate bounded backoff, conversation-history retrieval protection, and navigation/refetch fan-out across macOS desktop and web. No cookies, authorization headers, account details, private research contents, or unredacted log bundles are included here.
Follow-up recovery, 03:14–03:16 UTC: the same Global Equity conversation became accessible again after navigation paused. Its workbook and original input attachment were then downloaded through the desktop UI, without resetting the session or changing credentials. This reinforces intermittent retrieval/rate-limit behavior rather than missing stored content. Separately, two unfinished conversations returned
systemErrormetadata while the UI retained Thinking/Stop or Working controls andConnection interrupted. Waiting for the complete answer. That contradictory state requires reconciliation before restarting research.Follow-up on October 10, 2026: after signing into the in-app browser, all 17 project chats could be opened through that route. Eleven completed reports were recovered, including the two newly completed reports. Five remaining chats exposed partial research rather than final reports; four had active Stop controls. This does not establish deleted content or failed generation. No duplicate research was submitted.
A later desktop
navigate_to_codex_pageattempt for https://chatgpt.com/c/6ac9d68b-13f8-832e-8042-c36d806458e9 returned the exact errorChatGPT conversation history was rate limited, even though that report's original files had already been downloaded successfully. The tool exposed no HTTP status for this later failure. The signed-in in-app recovery and subsequent desktop failure indicate route-specific, intermittent availability; they do not establish a root cause. Original console and desktop-log evidence remains above.shanghaicouple888-code commentedon Oct 11, 2026
Additional Windows desktop reproduction on October 12, 2026 (UTC+8).
Desktop version: 26.1007.21434, build 13901, prod. Microsoft Store package version: 26.1007.2314.0. The official updater reported up_to_date.
Multiple saved ChatGPT conversations displayed "Unable to load this ChatGPT conversation". Inspected desktop errors contained GET /conversations/{conversation_id}, HTTP 429, and {"detail":"Too many requests"}. At least 20 failed requests across seven distinct IDs were logged by 2026-10-11 19:14:50 UTC. A later affected-history 429 was recorded at 19:37:08 UTC. These are inspected failures, not total traffic.
Short restarts did not clear the restriction. Account lookup succeeded; no 401/403 was found in the inspected scope. Two identical conversations were readable on web while desktop failed; one controlled web request returned HTTP 200, not disk cache. Same-chat retries around 60 seconds apart also occurred while the window was not visible. This may amplify traffic but does not establish the root cause.
After navigation was paused and chats were reopened serially with spacing, all four original chats temporarily displayed their message bodies again. However, reopening one of these chats at 2026-10-11 19:50:12.471 UTC reproduced HTTP 429 on its conversation-history GET and the desktop UI returned to the loading error. Recovery was therefore intermittent, and the four-chat stability check did not pass. No deletion, app reset, logout, reinstall, credential change, or project modification was performed.
Official in-app feedback was submitted successfully with full-conversation/diagnostic-log and all-browser-tab/log attachments deselected. Only a sanitized summary was sent. Feedback ID: 90b0b814-82a0-4a7f-9c86-d681f2fe2e05.
Please investigate bounded retry/backoff and overlapping conversation refetches, and provide an official mitigation or fix that preserves active work, histories, and project data. No private conversation IDs or bodies, account identity, screenshots, credentials, cookies, raw logs, or HAR are included in this public draft.
soup31314 commentedon Oct 14, 2026
I’m seeing this on ChatGPT Pro ($200/month) after clicking the Windows desktop update on October 14, 2026 and letting ChatGPT restart. Before that update/restart, my ordinary chats were opening. Afterward, I cannot open a single ordinary ChatGPT chat in either the Windows desktop app or my computer’s web browser. Codex worker chats still open on the computer, and I have had to use my phone for ordinary chats while using the computer for workers. This breaks a normal cross-chat workflow.
The desktop app currently reports version 26.1007.71326 (build 20398, prod). Existing ordinary chats still appear in the sidebar. A read-only attempt to retrieve three different ordinary chats returned the exact error
ChatGPT conversation history was rate limitedeach time; a Codex worker chat was readable. That tool did not expose an HTTP status, so I am not claiming I independently captured a 429. I also cannot prove the update caused the failure, but the onset immediately after the update/restart is a reproducible timeline OpenAI should investigate. The browser failing too means this is not confined to the desktop UI.Please check account-side conversation-history rate limiting and whether the updated desktop app’s startup/refetch behavior can trigger or prolong it. I need a supported way to restore access to my existing chats without deleting app data or recreating work, plus a clear incident/fix status.
Please do not close this with only “contact Support.” In a separate, acknowledged September 3 ChatGPT/Codex outage case, I spent about 38 days pursuing an accommodation. Support ultimately denied every option, acknowledged that discretionary accommodations were possible, and never gave me account-specific criteria for the denial. I have not claimed that Support has already investigated this new October 14 chat-loading failure. Given that experience, another generic referral to Support without technical follow-through would be a waste of time.
soup31314 commentedon Oct 14, 2026
Follow-up, October 14 (EDT): the phone is no longer a reliable fallback. The same “OpenAI support escalations” chat now shows
Message delivery timed out. Please try again.on the iPhone and a red{"detail":"Request timeout"}error in the other captured view after a reply appeared. This is in addition to ordinary chats failing to open on Windows desktop and in the computer browser. Codex worker chats on the computer were still responsive at the earlier check.The earlier comment described the phone as the only way I could access ordinary chats at that time. That has changed. A reply being visible does not mean message delivery or subsequent turns are working. Please investigate this as a cross-device conversation access/delivery problem, and preserve existing chats and in-progress work while fixing it.