Subject: Recurring image-reading failures in ChatGPT Pro across Windows, Mac mini, and Work mode, with conversation-history and messaging issues
Hello OpenAI Support,
I am an individual ChatGPT Pro subscriber. I have been experiencing recurring failures to read uploaded image attachments and would appreciate assistance from a human technical support agent.
- Timeframe and environment
The issue was repeatedly occurring at least during October 9–10, 2026, China Standard Time (UTC+8). The exact initial onset is not yet established.
Affected environments include a Windows computer and a Mac mini, the ChatGPT desktop apps and website, and both regular Chat and Work mode. Both new and existing Work tasks have been affected.
My network requires a proxy to access ChatGPT. Disabling the proxy prevents normal access. The image-reading problem also occurs with TUN/virtual network adapter and global proxy mode enabled.
- Main symptoms
-
After uploading an image, the attachment or filename may be visible, but the assistant sometimes cannot retrieve or read the original image or recognize its text.
-
Failure responses have included statements that the attachment is inaccessible, that the original image cannot be retrieved, and “download failed.”
-
The issue is intermittent: previously failing conversations have temporarily recovered and then failed again.
-
Conversation history has failed to load on the website, and the Recent and Projects lists have appeared incomplete, even after refreshing.
-
Message-stream errors and an inability to send messages from the Mac mini also occurred during the same period.
- Test results and troubleshooting attempted
After uninstalling and reinstalling the Windows app, one round of testing showed that regular Chat could read image text quickly and accurately. During the same period, Work successfully read several images, but took noticeably longer. Previously failing conversations also temporarily recovered. The image-reading failures subsequently returned.
In another test, both regular Chat and Work on the website could read images, while conversation history and the Recent and Projects lists remained abnormal. These successful individual tests do not establish that regular Chat or the website remained consistently unaffected.
Troubleshooting has included restarting the apps, signing out and signing back in, reinstalling the Windows app, and testing different devices, new and existing Work tasks, and desktop and web interfaces. Proxy, TUN, global proxy mode, and DNS-related conditions were also checked. These attempts have not produced a lasting, stable recovery.
- Historical errors and identifiers
All times below are China Standard Time (UTC+8). Some timestamps refer to assistant replies and should not be treated as exact request timestamps.
-
October 9, 06:24:
A troubleshooting reply reported HTTP 429 and conversation-reading failures. Windows Work could not read images, and conversation history was also failing to load. -
October 9, 14:08:
A previous troubleshooting reply reported an image-download HTTP 503, described as an upstream connection timeout. This timestamp comes from the historical logs described in that reply. -
October 9, afternoon:
An earlier assistant response reported Windows error 10013, described as network access being denied in the Work execution environment. The corresponding raw tool output has not been obtained. -
October 9, 19:56:19:
A saved recovery report, which has been read, records HTTP 403 and Cloudflare error 1010, with the following Ray ID:
a47d33992eaf5126-LAX -
Around 23:00–23:07 on October 9:
Windows and Mac troubleshooting replies reported HTTP 429, 500, and 503, together with “thread access denied,” “Too many requests,” a thread/read error code of -32003, and WebSocket-related errors.These records concern history lists, conversation reading, initialization, message preparation, and Work connections.
-
Around 23:34 on October 9:
A Windows package-repair operation was reported to fail with 0x80073D02 and subsequently complete with 0x0 and event ID 400. These are client-repair records, not image-download error codes, and do not establish stable recovery of image reading. -
October 10, 00:02–00:12:
Earlier assistant replies reported socket.gaierror with errno 8 when querying DNS for sdmntprcentralus.oaiusercontent.com. The reported output was:DNS FAILED: 8 [Errno 8] nodename nor servname provided, or not known
Those replies described the execution environment as Darwin/Python. The retrieved evidence contains assistant replies, not the original execution trace.
-
October 10, 04:06–04:07:
Two subsequent image-download attempts were reported to fail with only “download failed,” without a verifiable HTTP status code or underlying exception. -
Error frequency
Previous troubleshooting replies reported:
-
Windows: approximately 6,000 cumulative “thread access denied” entries, subsequently exceeding 6,200. The counting period was not specified.
-
Mac mini: 2,926 conversation-access denial entries and 2 image-download failure entries in that day’s logs.
-
Mac mini: another observation covering approximately 16 minutes reported 48 conversation-access denial entries and 6 HTTP 429 entries.
-
Mac mini: the reported error rate decreased from approximately 24 per minute before repair to approximately 2–4 per minute afterward.
- Recovery records and evidence limitations
The previous recovery report records that the same original image was successfully obtained through another authorized attachment route and read correctly, with matching file-integrity checks. This only establishes that the image could be read through that alternative route. It does not establish that the original failing download route was fixed or that the full workflow for newly uploaded images had recovered.
The errors above concern different times, requests, and execution environments. Most error details come from earlier assistant troubleshooting replies, and the corresponding raw tool logs have not been obtained. These error codes should not be treated as proof of a single root cause or a continuous progression of the same failure.
A separate HTTP 403 related to remote-control multi-factor authentication occurred during troubleshooting and is excluded from the image-reading failure evidence.
It remains unconfirmed whether the image-reading failures, conversation-history loading problems, and messaging issues share a common cause.
Thank you.