Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Copying a prompt out of a chat used to carry its context references with it. It no longer does
The first screenshot below shows the initial prompt, working as intended. Then I clicked in the prompt text box, copied all the text, pasted it in a new chat, and submitted (see second screenshot). The clipboard receives the rendered text of the mention and nothing else, so pasting that prompt into a new chat produces the bare string @TEST.md with no attachment behind it, and the composer does not re-resolve it on the way in.
The text that survives is not the text that was shown. The first chat displays the resolved reference, ai-context/temp/TEST.md. The paste yields @TEST.md. The directory is discarded, so the pasted prompt cannot be reproduced by reading it.
Where the file is outside what search can reach, this is not just a slower route to the same answer. The TEST.md above lives in a directory listed in .gitignore. Indexing and fast grep honor .gitignore, so the file is invisible to every search the agent has. The context reference was the only thing that could locate it, and the context reference is exactly what the clipboard dropped.
| Prompt | Result |
|---|---|
File attached from the @ autocomplete |
Contents returned. 3 s |
The same prompt copied and pasted, arriving as literal @TEST.md |
Reported as not present in any open project folder, with a request for a full path. 20 s |
A tracked file would likely be found by search regardless, which is what makes this easy to miss in an ordinary workspace and a blocker in an ignored directory. The failure is not that the agent is worse at finding files; it is that a prompt which named a file precisely now arrives naming it only approximately, with no sign that anything was lost.
The workaround is manual re-entry. Delete the pasted text for each mention, retype @, find the file in the picker, and select it — once per reference in the prompt. That removes most of the reason to copy the prompt in the first place.
Steps to Reproduce
- Create a directory covered by
.gitignoreand putTEST.mdin it containing1234. - In a new chat, type
Can you read:, then@, and pickTEST.mdfrom the autocomplete so it is attached as a context reference. - Send it. → The agent reads the file and answers with its contents.
- Copy the entire initial prompt message.
- Open a new chat and paste. → The composer receives the plain text
@TEST.md. There is no context attachment. - Send it. → The agent searches, does not find the file, and asks for a full path.
Expected Behavior
- Copying a prompt should copy its context. Re-running a prompt in a fresh chat by copying it out of an older one is the ordinary way to do that, and it is the workflow this breaks. Whatever internal form the references take, the copy should carry it and the paste should restore it. This is how it used to work.
- Failing that, a pasted
@nameshould be resolved by the composer. The composer already resolves@as it is typed. Text arriving by paste is the same text, and resolving it on paste would recover the attachment in every case where the name is unambiguous. - Failing that, the plain-text rendering should be the resolved path.
@ai-context/temp/TEST.mdon the clipboard would leave the prompt repairable by hand, and a path is frequently enough for the agent to open the file directly even where search cannot see it. A bare filename is enough for neither. - A prompt that lost its attachments should not be indistinguishable from one that kept them. Neither the user pasting it nor the agent receiving it has any way to tell that the prompt was complete when it was written.
Screenshots / Screen Recordings
Operating System
Windows 10/11
Version Information
Version: 3.21.16 (system setup)
VS Code Extension API: 1.128.0
Commit: 8ae78e8eee1e63479c7e0504b664bc0a80c68000
Date: 2026-09-19T06:43:22.276Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200
For AI issues: which model did you use?
Not model-specific — this is clipboard and composer behavior rather than model behavior. The two chats above differ only in what the composer sent; the agent’s handling of each was reasonable given what it received.
For AI issues: add Request ID with privacy disabled
N/A
Additional Information
This is a regression. Copying a prompt previously brought its context references along with it, and pasting it into a new chat reproduced the prompt intact.
Why the ignored-directory case is not a corner case. Scratch, notes, and AI-context directories are routinely gitignored precisely because they are working material rather than source, and they are also the directories a prompt is most likely to point at by hand. The same reasoning applies to anything excluded by .cursorignore. In those directories the context reference is not a convenience over search; it is the only mechanism that works. So losing it in a copy is the difference between a prompt that runs and a prompt that cannot.
Related Posts
This thread establishes that there are issues with using the UI attachment button or dragging files from file explorer into the chat. The suggested workaround was to use @ reference or drag from Cursor’s own Explorer view. So the current bug report makes the only usable way to attach context files more difficult to use.
The nearest precedent, and the same operation: select a message in one chat tab, copy it, paste it into another, and the @ references in it come out inert. Acknowledged in September 2025. The reporter returned a couple weeks later to note that plain URLs had been fixed while Past Chats links still lost their linkage after copy-paste. File references now behave the way those links did, which suggests that whatever carries a reference across the clipboard has been partially repaired before and is partially broken again rather than never having worked. The post was closed automatically 22 days after the last reply without any resolution from the Cursor team.
The same class of defect on a different context type: terminal output pasted into chat stopped arriving as a context block and began arriving as plain text, reported as a regression from 1.7.x to 2.0.10. Worth pairing with this one because the attach-or-leave-as-text decision has silently resolved to text before, on a different input path, after an update. The post was closed automatically 22 days after the last reply without any resolution from the Cursor team.
Does this stop you from using Cursor
No - Cursor works, but with this issue