Where does the bug appear (feature/product)? Cursor IDE Describe the Bug I’m developing a Streamable HTTP MCP server with OAuth support and noticed a change in Cursor’s behavior. Previously, Cursor sent the following redirect URI in the authorization request: cursor://anysphere.cursor-mcp/oauth/c…

Hi Tejaswini, We recently moved MCP OAuth in the IDE/CLI from the cursor:// custom-scheme deeplink to a loopback redirect, http://localhost:8787/callback. That’s the redirect style recommended for native apps in RFC 8252 , and we switched because a lot of OAuth providers won’t accept a custom-scheme…

Hey @mohitjain , I recently hit this while re-authenticating to the honeycomb mcp. It caused a .. sort of related bug. Here’s the summary from cursor itself: Symptom: OAuth consent on honeycomb.io succeeds, but the browser then fails to connect when redirected to http://127.0.0.1:8787/callback?..…

You’re right that this is a separate issue from the original thread: that one was a provider-side allowlist gap, whereas you’re hitting a genuine bug on our side — the MCP OAuth callback server binds to IPv6 loopback ([::1]:8787) only, so a provider that redirects the browser to IPv4 127.0.0.1:8787 …

Cursor’s OAuth redirect_uri is using a fixed localhost port (8787) that conflicts with quite a few things that might be running on a developer machine: Dask’s web interface, Cloudflare’s wrangler dev, probably some others. This breaks the OAuth flow if one of those apps happens to be running. Curso…

Good callout, and you’re right on the spec. The loopback callback currently uses a fixed port (8787), so if another local process is already sitting on that port (Cloudflare wrangler dev defaults to 8787, and Dask and a few others can land there too), the connect fails - Cursor either can’t stand up…

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug Cursor’s OAuth redirect_uri is using a fixed localhost port (8787) that conflicts with quite a few things that might be running on a developer machine: Dask’s web interface, Cloudflare’s wrangler dev, probably some others. Thi…

@mohitjain Hi, We are experiencing an OAuth authentication issue with a remote MCP server in Cursor. On some Cursor installations, the OAuth authorization request uses the previous callback: cursor://anysphere.cursor-mcp/oauth/callback On other installations, Cursor now generates: http://local…

Quick answers: Yes, intentional. MCP OAuth moved to the http://localhost:8787/callback loopback ( RFC 8252 ) because many providers reject the cursor:// scheme. Yes, a gradual server-side rollout, which is why installs differ with no change on your end. exthost is the older flow (uses cursor:…

This issue has broken Cursor’s ability to use the Algolia Productivity MCP - Get started with Algolia Productivity MCP - Algolia . [Shared MCP process] Transient error connecting to streamableHttp server: Redirect URIs do not match

OAuth redirect URI changed from cursor:// to http://localhost for Streamable HTTP MCP

Support Bug Reports

mp_hod (Michael Pearson) July 11, 2026, 1:55am 10

Re-raised here: MCP OAuth binds to IPv6 loopback, breaking 127.0.0.1 MCP redirect

Topic		Replies	Views
MCP OAuth callback changed to http://localhost:8787/callback and authentication still fails Bug Reports mcp , login	1	80	July 15, 2026
Linear MCP auth fails with “Invalid redirect URI” (cursor://anysphere.cursor-mcp/oauth/callback) Bug Reports mcp , linear , deeplinks , plugins , linear-linked	10	689	May 11, 2026
MCP Server Regression - MCP OAuth registration fails Bug Reports mcp	1	252	May 7, 2026
MCP PKCE oAuth flow is not using refresh token Bug Reports mcp , login	14	371	April 10, 2026
Cursor using wrong url for token exchange when authorizing an MCP server Bug Reports mcp	8	164	May 11, 2026

OAuth redirect URI changed from cursor:// to http://localhost for Streamable HTTP MCP

Related topics