/usr/share/cursor/cursor --open-url 'cursor://test' → does NOT open a new window
Hypothesis:
Callback is delivered via a new process/window instead of the existing Cursor instance,
so MCP OAuth callback is not routed to the active connection context.
Question:
Is this a known issue with cursor:// deep link handling or MCP OAuth on Linux?
Is there a way to force callback to be handled in the existing instance?
→ This opens a new Cursor window instead of reusing existing one
Expected Behavior
OAuth callback should be routed to the already running Cursor instance,
and MCP connection should complete in the original window without opening a new one.
On Linux, authenticating the built-in Linear integration (MCP OAuth) opens an additional Cursor window after the browser step. The OAuth callback does not complete; Linear stays disconnected. Closing all Cursor windows first does not prevent the extra window.
Environment
OS: Debian Linux x86_64 (kernel 6.12.74+deb13+1-amd64)
Cursor: 3.3.30 (commit 3dc559280adc5f931ade8e25c7b85393842acf30, x64), installed from .deb
Integration: Cursor Linear plugin / MCP auth flow (browser OAuth, then cursor://… callback)
cursor:// handler (sanity check)
$ xdg-mime query default x-scheme-handler/cursor
cursor-url-handler.desktop
/usr/share/applications/cursor-url-handler.desktop contains: Exec=/usr/share/cursor/cursor --open-url %U MimeType=x-scheme-handler/cursor;
So the URL scheme is registered and passes %U; the failure appears to be in tying the callback to the in-flight MCP auth session, not a missing handler.
### Steps to Reproduce
On Linux, open Cursor (single workspace is enough).
Start Linear MCP authentication (e.g. auth prompt for the Linear MCP server / plugin).
Complete login in the browser when redirected to Linear.
Observe: browser (or OS) invokes the cursor://… OAuth callback; Cursor opens another window (or process).
Original session never shows Linear as connected; auth does not finish.
### Expected Behavior
After browser login, the same Cursor instance that started OAuth should receive the callback and complete Linear MCP authentication without spawning a disconnected second window.
### Operating System
Linux
### Version Information
Version: 3.3.30
VSCode Version: 1.105.1
Commit: 3dc559280adc5f931ade8e25c7b85393842acf30
Date: 2026-05-09T18:28:42.332Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.12.74+deb13+1-amd64
### Does this stop you from using Cursor
No - Cursor works, but with this issue
Thanks for the detailed report, Alexander. This is the same known bug — your cursor:// handler sanity check confirms the same mechanism (callback launches a new process instead of routing to the running instance).
Good to know it reproduces on Debian with the latest version too.
Workaround for Linear: You can bypass the OAuth flow by running the Linear MCP server locally with an API key. Generate a personal API key from Linear Settings > API > Personal API Keys, then add this to your MCP config:
We’ve reworked how MCP authentication completes since you posted — the callback no longer depends on the system routing a cursor:// link back to the running app, so the extra-window behavior you traced shouldn’t block connecting anymore. Could you give it another try on the latest version?
Quick check:
Update Cursor to the latest version
Connect the Notion MCP server and complete the login in your browser
Check that the connection becomes authenticated in your original window
Let me know if the OAuth flow still doesn’t complete on Linux!