The agent produced a chat response with a link to a file it had just created. I clicked on the link and got the error title=“Unable to open ‘’” message="Unable to resolve resource “”.
Steps to Reproduce
Have agent create a local file and provide a link to that file in the chat (I didn’t prompt it to do that, it just did). Click on link to view file. Error.
Thanks for the report @rory77235! There’s a known issue where windows drive-letter paths in chat markdown links are misidentified as URI schemes. I’ve added your report to the bug ticket where we’r tracking this!
Describe the Bug
On Windows, clicking a local file link generated in the Chat/Agent panel fails to open the file. Cursor shows an “Unable to open …” dialog with the message “Unable to resolve resource”, and the path in the error is displayed percent-encoded — the backslashes appear as %5C instead of being decoded back to .
It looks like the resource resolver does not decode the %5C sequences. Instead of resolving the path, it appears to look for a literal path that contains %5C, which of course does not exist — hence the “resolve” failure.
Example error detail:
C:%5CUsers%5C%5CDesktop%5Cexample.docx
(the actual path is C:\Users<user>\Desktop\example.docx)
This started after a recent update, so it looks like a regression. It affects both clickable file links and “Open file” actions, regardless of file type (reproduced with .docx, but the encoded path is the root issue).
Steps to Reproduce
On Windows, have the Agent create or reference a local file and produce a clickable link to it in chat (e.g. C:\Users<user>\Desktop\example.docx).
Click the link / “Open” button.
Observe the “Unable to open … / Unable to resolve resource” dialog showing the %5C-encoded path.
Expected Behavior
The link resolves and opens the file — or, for non-text files such as .docx, hands it to the OS default application.
Actual Behavior
“Unable to resolve resource” with a percent-encoded (%5C) Windows path; the file never opens.
Workarounds found
Opening the same file via Ctrl+P (Go to File) works.
Writing the path with forward slashes (C:/Users//Desktop/example.docx) or as a file:/// URI avoids the problem, since no %5C is produced.
“Developer: Reload Window” sometimes helps temporarily.
Follow-up: works fine in a competing VSCode-based IDE — this is a Cursor regression, not a platform limitation
To add a data point that I think strengthens the hotfix case: I tested the same workflow in TRAE, which is also a VSCode fork (see attached About screenshot). There, every Agent-generated file link resolves correctly on Windows — clickable links with Windows paths just work, no workarounds needed.
Worth noting the version, too: TRAE is still based on VSCode 1.107.1, i.e. an older upstream than current Cursor builds. So this clearly isn’t an upstream VSCode/Electron limitation that everyone inherits — an older VSCode base handles the path-to-URI normalization just fine. That points squarely at a regression in Cursor’s own link-generation code, which is consistent with my earlier observation that this broke after a recent update.
In short: a competitor on an older VSCode base ships working agent links on Windows, while Cursor’s are dead on click. I hope this helps prioritize it as a hotfix rather than a normal-cycle fix. Screenshot attached for reference; happy to provide anything else that helps.
When I don’t like an agents work, I try it again with a different model. Suddenly that’s broken. New agent chats suddenly started using files created by previous agent chats, with a completely clean working directory. I asked the agent and it said it was initialized with a stale git snapshot. The two possibilities suggested in reply to the linked issue seem to be both mistaken ignore what that previous issue said.
I’m using a different model, so its not model determinism.
working directory is definitely clean, no untracked files, nothing in git clean -nd
I keep opening new agent tabs, in the sidebar with the + sign. and it keeps having a stale git snapshot, even though I cleaned my git before opening the tab. Retrying agent builds is part of my basic workflow, so really need a way to get clean agents.
Thanks for your help
Steps to Reproduce
Open agent and ask to write code files
Undo all changes, and delete all newly created files
Ask agent about old files, it will mention specific details, and say it can see them in git snapshot
