[Web Bug] Unsent draft attachments were accessed by an in-progress assistant turn

Open 💬 2 comments Opened Aug 6, 2026 by styx-000

What issue are you seeing?

On the ChatGPT Work web interface, an assistant turn that was already in progress accessed information from screenshots that had been pasted into the composer for a follow-up message but had not been sent.

Before the draft message was submitted, the in-progress assistant turn referenced specific information that was available only in those screenshots.

This indicates that content from attachments in an unsubmitted draft became available to an assistant turn that had started before the attachments were added. This crosses the expected boundary between drafting and submission. Content in an unsent follow-up draft should not influence an earlier turn under any circumstances.

What steps can reproduce the bug?

  1. Submit a prompt requesting a relatively long-running analysis of the same topic shown in the test screenshots.
  2. While the assistant is still working, paste screenshots containing a unique, task-relevant detail that does not appear elsewhere in the conversation into the follow-up composer, but do not send them.
  3. Leave the screenshots in the unsent draft until the original assistant response is complete.
  4. Observe whether the original response references the unique detail available only in the unsent screenshots.

What is the expected behavior?

Content from draft attachments should remain unavailable to the in-progress assistant turn and any related retrieval systems until the user explicitly submits the message. Adding an attachment to the composer or displaying its preview should not be treated as submitting it.

Additional information

  • Subscription: ChatGPT Pro
  • Product: ChatGPT Work
  • Platform: Web
  • Operating system: macOS
  • Date observed: August 6, 2026

Follow-up Privacy and Transparency Concern
Based on my observation, attachments are uploaded to the backend as soon as they are added to the Web composer, before the associated message is sent. This may be an intentional part of the product design, such as supporting attachment previews or pre-processing.

However, after I removed an attachment from the unsent draft, its content remained accessible to the model. This indicates that removing the attachment from the composer removed only its visible preview, but neither deleted the corresponding backend copy nor revoked the model’s access to the uploaded content.

This behavior should be explicitly disclosed to the user. A user may reasonably interpret removing an attachment before sending the message as withdrawing that file and making its content unavailable to the model. Without clear disclosure, this behavior raises a potential privacy and transparency concern.

This concern applies only to attachments removed from drafts that were never sent. It is separate from the handling of attachments included in submitted messages.

View original on GitHub ↗

2 Comments

ded-furby · 21 days ago

Thanks for reporting this and including a clear repro. Could you confirm whether the attachment bytes are ever uploaded for unsent drafts in your environment (for example by checking network/activity logs in the browser plugin panel) and whether removing the draft attachment clears any temp object IDs on the wire? The behavior matches a likely draft-state race: attachment content can become visible to the assistant once pre-uploaded before explicit send, so a log timestamp for upload versus attachment insertion would help confirm if this is a pre-send staging vs streaming context window issue.

styx-000 · 21 days ago

Thanks for looking into this. After discussing the behavior with the AI agent, I identified a possible mechanism behind the issue. The agent cannot directly access content in the unsent composer. However, once a screenshot is pasted, it is pre-uploaded and indexed by the backend. During a multi-step task, the agent invoked the personal_context tool (mcp__codex_apps__personal_context_search), which returned the unsent draft screenshot and its OCR content. As a result, the agent received information from the screenshot before the message was submitted. The same behavior persists even after removal: attachments can still be retrieved by the personal_context tool after being removed from an unsent draft. Based on this, I suspect that the personal_context tool may not be properly isolating unsubmitted draft attachments.