Chat: re-attaching a file after removing it from context does nothing

[villepispa]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

hen a file is attached to a Cursor Chat panel and then removed from the composer
input, the chat’s internal attachment-tracking set is not cleared. Any subsequent
attempt to re-attach the same file in the same chat session is silently discarded.

The chat composer likely maintains a Set (or equivalent) of already-attached files
to prevent duplicate context entries. Removing the file clears it from the visible UI
but not from the deduplication set. On re-add, the guard fires — treating the file as
already present — and silently drops the request. A new chat starts with an empty set,
which is why re-add succeeds there.

This breaks the natural workflow of attaching a file, reading context, removing it to
reduce token usage, and re-attaching later in the same conversation — forcing the user
to open a new chat and lose conversation history.

Steps to Reproduce

1. Open a new Cursor Chat panel.
2. Click Add File (or type @) and select any file — e.g. README.md.
3. Confirm the file appears in the chat context / composer.
4. Remove the @README.md reference from the composer (delete it or click ✕).
5. Click Add File again and select the same README.md.
6. Observe: file does not appear; the add is silently ignored.
7. Try Add File → select a different file: succeeds.
8. Open a new chat → Add File → select README.md: succeeds.

Expected Behavior

Removing a file from the composer input fully clears it from the internal attachment
tracking, so it can be re-added in the same chat session without issue.

Operating System

Windows 10/11

Version Information

2.7.0-pre.151.patch.0

Additional Information

After removal, the file remains registered in the internal deduplication set. A
subsequent Add File for the same file is silently dropped — no error or feedback is
given to the user. A different file can be added successfully, confirming the Add File
command itself is functional.

Related threads (not duplicates): #146621 (first add fails in Agent mode) and #152021
(right-click add unreliable in Agent mode) — both describe initial add reliability,
not re-add after removal.

Fix area: removeFile() should delete the entry from the deduplication set, not only
from the visible UI. Symmetric: add → tracked; remove → untracked.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed bug report, especially the repro steps and the root cause hypothesis.

This is a known issue. Removing the file pill from the composer clears it from the UI, but it doesn’t fully untrack it internally, so you can’t add the same file again. The team is aware of this and tracking it.

For now, the workaround is what you already found: start a new chat session. Not ideal if you want to keep the conversation history, but it’s the only reliable option right now.

Your report helps with prioritization. We’ll post an update here if there’s progress on a fix.