On Win10 i have a symlink folder and no matter how many times I tag the file Cursor say it’s unable to access the file.
The strange thing is Cursor was able to create a file in the same symlink folder… and then later it was unable to access back the file it created earlier in another chat
Hey, thanks for the report. Symlink issues are a known area with a few open bugs, but your specific case (the agent can’t read files via @ inside a symlinked folder) seems unique so far. To share this with the team with enough context, I’ll need a bit more detail:
Your exact Cursor version: Menu → About Cursor → Copy
What type of symlink are you using? (mklink /D, mklink /J, or mklink with no flags)
A screenshot or the exact error text when the agent says it can’t access the file
The Request ID from the chat where you can reproduce it (top-right of the chat → Copy Request ID)
Also, as a workaround, try opening the target folder directly (not through the symlink) as the workspace in Cursor and see if file access works that way.
Let me know what you find and I’ll pass it to the team.
It just happened again. The agent created a file in the symlink folder. Then I asked to do some modifications in another chat, and the agent couldn’t access the file so it forgot it existed and created a completely different file, made me waste time and burn token until I realized what happened.
Then I tagged the exact file in the symlink folder, and agent said it couldn’t access it:
And the strange thing is that if I insist a lot (pardon the bad language lol) then the agent will finally be able to locate the file. But sometimes it argues over and over again that it can’t access it.
It’s getting worse. Now the agent completely overwrites the files in the symlink folder because it think the file I asked for doesn’t exist so it creates it. Absolutely frustrating experience.
Thanks the screenshots and all the Chat IDs - thanks for the detailed info, this is exactly what was needed.
The problem is clear: the agent can write through the symlink but can’t read back, and as a result, it overwrites files - that’s really frustrating, especially when tokens are at stake.
As a workaround for now, try opening the target folder (where the symlink points) directly as a workspace instead of working through the symlink. This should eliminate the issue with reading files.
Why were my posts deleted for simply reporting a bug? This is outrageous censorship. My posts were polite and didn’t break any rules. I was simply trying to help by reporting a bug, but you obviously care more about silencing complaints than fixing actual bugs. Very disappointing from Cursor to be treated like that after wasting an entire day on your bugs and doing the effort to report them.
