WSL: chat/editor links to Windows paths (C:\...) fail — "Unable to resolve resource" on double-click

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When working in a WSL remote workspace, clicking or double-clicking file paths that point to the Windows filesystem does not open the file.

Example: agent copies an HTML template to C:\Users<username>\Desktop\example.html and shares the path in chat. Clicking the link or double-clicking from the editor shows:

  • “Unable to open ‘\Users<username>\Desktop\example.html’”
  • “Unable to resolve resource C:%5CUsers%5C%5CDesktop%5Cexample.html”

Also fails for malformed cross-boundary links such as file:///C:/home//… (Windows drive letter mixed with a Linux home path).

Files under the WSL workspace path (e.g. /home//my-project/…) open fine. Only Windows absolute paths (C:...) and cross-boundary links are broken.

Related prior report (same WSL setup):

Steps to Reproduce

  1. Windows 11 + WSL2 (Ubuntu)
  2. Open folder from WSL: cursor . in /home//my-project
  3. Create or copy a file to Windows Desktop, e.g. C:\Users<username>\Desktop\test.html
  4. In Cursor chat, click the C:... path link OR try to open that path from the editor
  5. Error modal: “Unable to resolve resource”
  6. Double-click on Desktop file from Cursor context also blocked when path is Windows-side

Expected Behavior

  • Clicking a C:\ path in chat should open the file (browser for .html, or system default app)
  • OR Cursor should translate WSL ↔ Windows paths (/mnt/c/Users//… ↔ C:\Users<username>...)
  • OR chat should not render C:\ links as clickable editor URIs without a clear “open in Explorer” action

Operating System

Windows 10/11

Version Information

IDE Version: 3.8.11
VSCode Version: 1.105.x (bundled with Cursor 3.8.11)
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0

For AI issues: which model did you use?

N/A — IDE / WSL path resolution issue, not AI model specific

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Workaround that works:

  • Open file from Windows Explorer (double-click on Desktop)
  • Use WSL path inside workspace: /home//my-project/communication/example.html
  • Paste in browser: file:///C:/Users//Desktop/example.html

Impact: friction when agent delivers email attachments (HTML templates) on Windows Desktop while dev environment is WSL — user expects chat links to be clickable.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. There are actually two separate things here, so I’ll split them up.

  1. Error Unable to resolve resource C:%5C...
    This is a known parsing bug. Windows paths with a drive letter C:\... in chat links get incorrectly detected as a URI scheme, so the backslashes get percent-encoded %5C and the file won’t open. The bug is logged, but I can’t share a timeline for a fix yet. Once there’s an update, I’ll post it in the thread.

  2. Opening C:\... files from a WSL workspace
    This is separate, and it’s by design. When you open a project via WSL remote, the editor is working in the WSL filesystem, and Windows host paths like C:\Users\... just don’t exist from that context. Even after the parsing fix, that path still won’t open directly because it isn’t reachable from WSL.

What works right now:

  • Reference the Windows file through the WSL mount: /mnt/c/Users/<username>/Desktop/example.html
  • If you want chat links to stay clickable, ask the agent to write files inside the WSL workspace /home/<user>/... instead of the Windows Desktop
  • Your workarounds are also valid, like opening it from Explorer or pasting file:///C:/... into the browser

So mapping WSL ↔ Windows paths is more of a feature request than a fix for a single bug. Let me know if any of the workarounds don’t work for you.