Repository navigation
[ChatGPT Web] Two assistant responses show "This response couldn't load" even after hard refresh #53164
Description
Summary
On October 11, 2026, around 18:20 CEST (Spain), two consecutive assistant replies in a ChatGPT Web conversation were replaced by the message:
This response couldn't load
Other replies in the same conversation still displayed normally.
Environment
- Product: ChatGPT Web (not the Codex app)
- Subscription: ChatGPT Plus
- Browser: Google Chrome
- OS: Windows
- Approximate time: October 11, 2026, 18:20 CEST
Steps to reproduce / observed behavior
- Continue an existing ChatGPT conversation that includes user-uploaded chart screenshots.
- Request explanations; assistant messages may contain rich formatting, diagrams, or other visual elements.
- Two assistant responses fail to render and are replaced with "This response couldn't load".
- Force-refresh the page without cache.
- The same two messages still fail to load, while other messages remain visible.
The error was reported across consecutive replies in the same conversation; it is not yet known whether rich content is the cause.
Expected behavior
Previously generated assistant replies should display reliably after page reload. If a response cannot be rendered, ChatGPT should offer a functioning recovery mechanism without losing the reply.
Actual behavior
Two assistant replies remain inaccessible despite a hard reload without cache.
Impact
Interrupts an active paid-user conversation and prevents the user from reading generated answers. Standard browser refresh troubleshooting did not resolve it.
Additional context
The user has a screenshot showing both failed replies in the same conversation. No private conversation content or personal information is included in this public report. Screenshot can be provided through an appropriate support channel upon request.
Routing note: This is a ChatGPT Web issue, not necessarily a Codex bug. It is being filed here because the user requested a public GitHub report in this OpenAI repository. Please redirect to the appropriate ChatGPT team or tracker if possible.
Activity
sw8496 commentedon Oct 17, 2026
Privacy Badger was causing this error for me. I white listed chatgpt.com to fix it.
drevendev commentedon Oct 18, 2026
Additional recurring ChatGPT Web observations — October 18, 2026
I am seeing the same per-response symptom in an existing long ChatGPT Web conversation, with the interface in Russian. Several assistant answers become unreadable while surrounding user messages and the conversation remain available.
Screenshots supplied in the affected conversation show:
These durations are visible UI labels, not backend execution traces or measured timeouts. The affected requests were ordinary planning/explanation requests; some answers were long and contained links/rich formatting. This is context, not evidence that length or rich content caused the failure. There is no controlled minimal reproduction yet.
Observed sequence: use an existing conversation → request a detailed response → response becomes inaccessible or displays the localized load error → ask for the answer again → the symptom recurs. New follow-up messages can still be sent. Whether the original message was lost server-side, failed to hydrate, or merely failed to render is unknown.
Important distinction from earlier comments: I have not established whether a browser extension is involved, and have not completed an extension-free/incognito comparison. I am not claiming the original reporter's hard-refresh test was reproduced on my account, or that the Privacy Badger workaround applies to this case.
Please investigate per-message retrieval/rendering/reconnect handling and offer a way to recover the existing response as plain text without regenerating the answer or replaying any associated tool writes. A blank response must not be treated as proof that prior external actions failed.
Product is ChatGPT Web, not a reproduced open-source Codex CLI defect; please route to the ChatGPT conversation/UI team if appropriate. Exact failing model/build, message/request IDs, HAR and console logs are not available in this public report. Private conversation text, account identifiers and unredacted screenshots are deliberately omitted.