I use Dot in ChatGPT on the Windows web interface for a daily document workflow. Native attachment delivery worked on October 19, 2026, but failed on October 20.
What happened:
Dot generated the Word and Excel files successfully, but could not deliver them as downloadable attachments in the chat.
At 17:26:16 on October 20, 2026 (UTC+8), the upload workflow failed before an upload session was created, with this error: hosted apps tools/list request failed with HTTP status 403.
Ordinary Library read/list operations were still working. This was not a failure to generate the documents, and the error occurred before the file contents were uploaded.
Troubleshooting found a difference in the upload component’s default endpoint between the successful and failed runs: /backend-api/wham/apps versus /backend-api/ps/mcp. This is a lead for investigation, not a confirmed root cause. I do not have server-side logs, and I am not claiming that all users are affected.
A workaround eventually delivered the files by uploading them to my own Google Drive with permission, then downloading them to my Windows desktop. The files were verified successfully. That alternative route does not show that the original ChatGPT attachment workflow has recovered.
For a workflow that requires usable documents every day, this blocks the core result: the work is generated, but the user cannot receive it through the expected attachment route. Requiring an unfamiliar external storage service as a workaround adds substantial friction.
Please investigate whether there is a permissions or routing regression affecting Dot’s native Library upload/attachment delivery. Is there a supported recovery step, or a known issue being tracked? A support report has also been sent through the Help Center. No private documents or credentials are included here.
Hi Armywas, I’m encountering the same error in ChatGPT Work while updating a research note.
The PDF and complete LaTeX source ZIP are generated successfully, and the source package compiles correctly. However, replacing the existing saved files fails with:
hosted apps tools/list request failed with HTTP status 403
Library searches still work. This happened on October 20 and is continuing on October 21, Japan time.
This matches the failure pattern you described. I haven’t independently verified the endpoint difference you mentioned, so I can’t confirm the underlying cause.
Have you received any response from OpenAI or found a supported fix? Thanks for documenting this.
I’m seeing the same issue across multiple ChatGPT chats on October 20. File reads and searches work, but saving or replacing files fails before upload with “hosted apps tools/list request failed with HTTP status 403.” I use Android beta and have also encountered it through my assistant’s cloud web workflow. Has anyone found a confirmed fix?
My dot, Ada, came up with a contingency process for saving several related documents one at a time while the normal Library save helper is failing. We have now tested it on five new dummy files, not our real project documents.
The procedure:
Preserve the originals and freeze the reviewed replacement text. Record each file’s identity, current version and intended changes before starting.
Use the supported direct single-file save operation, with the expected-current-version guard. Keep one writer and save in dependency order, with the index or summary document last.
After each successful save, verify the returned identity/version and read back the entire file. Compare all the content and size with the intended replacement, then record a checkpoint before moving on.
If the read still shows the old contents, do not repeat the write. Wait briefly and re-read. Advance only when the saved version, backing-file identity and full contents match. Stop if visibility does not resolve or an unexpected newer version appears.
At the end, read and reconcile the whole set. A partially completed batch stays incomplete; do not treat individual successes as proof that all documents are consistent.
All five guarded updates passed, including the final cross-file check. We also tested a controlled pause/resume, simulated a missing local save receipt and reconciled without duplicate writes, and deliberately used a stale expected version. That last test returned a conflict and did not overwrite the newer content.
The rehearsal caught a useful wrinkle: two files initially read back their old contents despite successful save receipts. Later read-only checks showed the correct saved contents. No second write was needed.
We have added a configurable short wait and bounded read-only rechecks to the process. Our proposed timing is an initial 2-second pause, then waits of 2, 4, 8 and 15 seconds between further checks, with a 60-second observation budget. Those timings are a practical starting point, not a proven latency guarantee.
This is a tested five-file contingency, not an atomic transaction or a fix for the broken helper, and it does not establish reliability for every document or account. Our verification compared complete text and size, explicitly accounting for an omitted terminal newline in the read response; it was not a raw remote-byte hash comparison. We have not switched our real project over.
Only try this with disposable files first, where your available tools and permissions support direct saves. Do not bypass an access denial or remove version guards. I’m sharing the procedure because it may help others test a fallback safely while OpenAI investigates the normal save path.