MCP OAuth not completing on Ubuntu (cursor:// callback opens new window)

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

MCP OAuth flow (Notion) does not complete on Ubuntu.

OAuth starts correctly:

  • Browser opens
  • Login succeeds
  • Redirect to cursor:// happens

However, instead of completing authentication:

  • a new Cursor window opens
  • the original window (where MCP connection was started) stays in “needsAuth”
  • connection never becomes authenticated

Logs show:
OAuth provider needs auth callback during connection
Connect failed after auth_required; returning needsAuth

Investigation:

  • x-scheme-handler/cursor is correctly registered
  • cursor.desktop uses:
    /usr/share/cursor/cursor --open-url %U

Manual tests:

  • xdg-open 'cursor://test' → opens NEW window
  • gio open 'cursor://test' → opens NEW window
  • /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?

Steps to Reproduce

  1. Install Cursor via apt on Ubuntu
  2. Configure Notion MCP:
    {
    “notion”: {
    “url”: “https://mcp.notion.com/mcp”
    }
    }
  3. Open Cursor (single window)
  4. Trigger MCP connection (Notion)
  5. Complete OAuth login in browser
  6. Observe redirect to cursor://

Result:

  • New Cursor window opens
  • Original window remains in “needsAuth”
  • MCP connection does not complete

Additional check:
Run:
xdg-open ‘cursor://test’

→ 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.

Operating System

Linux

Version Information

Version: 3.1.17
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
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.8.0-110-generic

Additional Information

OS: Ubuntu 22.04.5 LTS

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Have same issue on debian

7

Describe the Bug

Summary

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
9

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:

{
"linear": {
"command": "npx",
"args": ["-y", "@linear/mcp-server"],
"env": {
"LINEAR_API_KEY": "lin_api_YOUR_KEY_HERE"
}
}
}

This runs locally and skips the cursor:// callback entirely.