[Windows + Remote] Chat/agent file links trigger "Get an app to open this 'vscode-file' link" Microsoft Store popup, across all agents

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Where does the bug appear: Cursor IDE — Agent/Chat panel, Windows client connected to a remote Linux workspace (cursor-server / SSH-style remote)

Environment:

Cursor version: <FILL IN from Help → About>
OS (client): Windows 11
Workspace: remote Linux (cursor-server), accessed from Windows desktop client
Started: immediately after a recent Cursor update
Summary: When interacting with agent/chat threads, Windows shows a popup: “Get an app to open this ‘vscode-file’ link — Your PC doesn’t have an app that can open this link. Try looking for a compatible app in the Microsoft Store.” Cursor is handing an internal vscode-file:// URI to the Windows shell instead of resolving it in-app. This appears to be the same underlying URI-handling regression as the acknowledged “Unable to resolve resource %5C” chat-link bugs, but in my remote-workspace setup it surfaces as the OS “vscode-file” store-popup variant rather than an in-app error.

Steps to reproduce:

Windows client connected to a remote (Linux) workspace via cursor-server.
Open an agent/chat thread that references local resources/file paths.
Click into the thread (or a rendered link/image).
Windows shows the “Get an app to open this ‘vscode-file’ link” dialog.
Impact:

Happens across all agents/threads, not just one — recurring and disruptive.
What I’ve ruled out:

Not hooks: no hooks in Cursor Settings → Hooks; no hooks.json anywhere in the remote ~/.cursor or ~/.claude configs; no plugins registered.
Not chat-specific content: initially seemed tied to a thread with pasted images, but it occurs in threads with no embedded images too.
Not credentials/MCP-related.
OS-side workaround (registering a vscode-file handler in HKCU\Software\Classes) does not address it — root cause is Cursor externalizing an internal URI.
Expected behavior: vscode-file:// URIs should be resolved internally by Cursor and never handed to the OS shell.

Steps to Reproduce

Setup: Windows desktop client connected to a REMOTE Linux workspace (cursor-server / SSH-style remote).

  1. Open Cursor connected to a remote Linux workspace.
  2. Open or click into any agent/chat thread that references local resources or file paths.
  3. Windows shows a popup: “Get an app to open this ‘vscode-file’ link — Your PC doesn’t have an app that can open this link. Try looking for a compatible app in the Microsoft Store.”
    This happens across ALL agents/threads, not just one, and started right after a recent Cursor update. Cursor appears to be handing an internal vscode-file:// URI to the Windows shell instead of resolving it in-app. Likely the same URI-handling regression as the acknowledged “Unable to resolve resource %5C” chat-link bugs, but in a remote-workspace setup it surfaces as this OS store popup.
    Ruled out on my side: no hooks configured (empty Hooks panel, no hooks.json), not tied to a specific thread’s content (occurs in threads with no embedded images too), not credentials/MCP-related.
    Related threads:
    Unable to resolve resource
    Unable to open file linked in chat

Expected Behavior

vscode-file:// URIs should be resolved internally by Cursor and never handed to the Windows OS shell, so no “Get an app to open this link” dialog appears.

Operating System

Windows 10/11

Version Information

Version: 3.12.10 (user setup)
VS Code Extension API: 1.128.0
Commit: 24a12dbd9cabf48956ce5bb3dbd234e41385b3d0
Date: 2026-07-16T03:15:48.538Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey there!
Thanks for the excellent report - your ruling-out is spot on, and this is a real bug on our side, not your setup. It’s part of a known family of Windows link-handling bugs where certain file links in the agent/chat UI get handed to the OS instead of opening in-app, which is what triggers that “Get an app to open this link” popup. We’ve seen this reported before, and I’ve logged your remote-workspace case with the team.

A couple of things in the meantime:

  • Feel free to revert the HKCU vscode-file handler you added - it won’t help here and isn’t needed.
  • Use Ctrl+P (Go to File) to open any file the agent references by name; that path works reliably.

One thing that would help us pin down the fix: where exactly are the links you’re clicking - the main agent/chat response, the inline “Questions” panel where the agent asks you something, a plan, or somewhere else? On a remote workspace that’ll tell us which view is leaking the link.

8

Thanks for looking into it!

To answer your question: it’s none of the interactive elements — it fires just from OPENING/SELECTING a thread in the sidebar, before I click anything inside it (not the chat response, not the Questions panel, not a plan). Simply switching to / loading a thread triggers the popup.

More detail:

  • It happens across multiple threads/agents, not one specific thread.
  • Setup is a Windows desktop client connected to a remote Linux workspace (cursor-server).
  • So it looks like the leak happens during thread load/render/hydration, not from clicking a rendered link.

Ctrl+P works fine for opening files, thanks — and I’ve reverted the HKCU vscode-file handler as you suggested.

Happy to help reproduce or answer any questions.

9

The fact that it fires on just selecting or loading a thread, before you click anything, is exactly what helps us narrow down which view is leaking the link, so I’ve noted it alongside your report.

To be clear, this is still on our side, not your setup, and Ctrl+P stays the reliable way to open any referenced file in the meantime.

Since you offered to help: if it’s easy, a short screen recording of you selecting a thread and the popup appearing (with your cursor visible) would help us confirm whether it’s tied to something rendering as the thread loads. No worries if not, we’ve got enough to keep digging either way.