Summary
coder:// / vscode://coder.coder-remote/open?... deep links silently do nothing when the editor routes the URI to an "agent window" (VS Code Agents window, Cursor Agents window / Glass). These windows run a restricted extension host that does not load third-party extensions, so the extension is never activated and its registered vscode.window.registerUriHandler callback is never invoked.
The renderer logs the URI as handled, so no error is surfaced. The link appears to do nothing.
Reproduction (as reported for Cursor)
- Install
coder.coder-remote 1.15.2.
- Start Cursor 3.14.7 on Linux with a clean
HOME and the default ~/.cursor/extensions directory.
- Open
cursor://coder.coder-remote/open?workspace=test&url=https://coder.example.com.
- Repeat after initialization completes.
Observed: renderer.log records the URI as handled, but extension-host initialization does not include coder.coder-remote, and there is no activation or URI-handler entry. On the repeat attempt, Cursor invokes workbench.extensions.installExtension even though the extension is already installed.
Expected: the installed extension is loaded and its onUri handler is invoked.
Upstream reports
Why this matters
Deep links are the primary entry point from the Coder dashboard ("Open in VS Code" / "Open in Cursor"). If the user's active or only window is an agent window, the flow fails with no feedback.
Scope
Tracking. The root cause is in the editor, not in this extension, so the work here is likely limited to:
- Confirming which editors and versions are affected (VS Code stable/insiders, Cursor, Devin, VSCodium).
- Confirming whether the Cursor fix has shipped and in which version.
- Deciding whether to document the workaround in the README or in the Coder docs deep-link section.
- Investigating whether anything in
package.json (for example an explicit onUri activation event, or extension kind metadata) changes whether the extension is loaded in these windows.
Summary
coder:///vscode://coder.coder-remote/open?...deep links silently do nothing when the editor routes the URI to an "agent window" (VS Code Agents window, Cursor Agents window / Glass). These windows run a restricted extension host that does not load third-party extensions, so the extension is never activated and its registeredvscode.window.registerUriHandlercallback is never invoked.The renderer logs the URI as handled, so no error is surfaced. The link appears to do nothing.
Reproduction (as reported for Cursor)
coder.coder-remote1.15.2.HOMEand the default~/.cursor/extensionsdirectory.cursor://coder.coder-remote/open?workspace=test&url=https://coder.example.com.Observed:
renderer.logrecords the URI as handled, but extension-host initialization does not includecoder.coder-remote, and there is no activation or URI-handler entry. On the repeat attempt, Cursor invokesworkbench.extensions.installExtensioneven though the extension is already installed.Expected: the installed extension is loaded and its
onUrihandler is invoked.Upstream reports
cursor://links for third-party extensions can be handled in the Agents window, where the extension does not load, soonUridoes not fire. A fix was said to be prepared.(https://code.visualstudio.com/docs/agents/run/agents-window), which has the same restricted extension host. Related upstream issues:
Why this matters
Deep links are the primary entry point from the Coder dashboard ("Open in VS Code" / "Open in Cursor"). If the user's active or only window is an agent window, the flow fails with no feedback.
Scope
Tracking. The root cause is in the editor, not in this extension, so the work here is likely limited to:
package.json(for example an explicitonUriactivation event, or extension kind metadata) changes whether the extension is loaded in these windows.