# MCP OAuth callback changed to http://localhost:8787/callback and authentication still fails

**URL:** <https://forum.cursor.com/t/mcp-oauth-callback-changed-to-http-localhost-8787-callback-and-authentication-still-fails/165752>\
**Category:** Bug Reports\
**Tags:** mcp, login\
**Created:** [July 14, 2026, 10:51pm UTC](https://forum.cursor.com/t/mcp-oauth-callback-changed-to-http-localhost-8787-callback-and-authentication-still-fails/165752 "2026-07-14T22:51:35Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\
**Post date:** [July 15, 2026, 10:43am UTC](https://forum.cursor.com/t/mcp-oauth-callback-changed-to-http-localhost-8787-callback-and-authentication-still-fails/165752/6 "2026-07-15T10:43:50Z")

</div>

Hey there! This is expected behavior, not a regression, and it’s fixable on your side. We recently switched MCP OAuth in the desktop IDE to `http://localhost:8787/callback`, though some installs still fall back to the old `cursor://` one, which is why it looks inconsistent.

Fix: in your OAuth client, allowlist both of these and keep both registered:  
`http://localhost:8787/callback`  
`cursor://anysphere.cursor-mcp/oauth/callback`

That way whichever callback a given install sends will match. There’s no `mcp.json` field or setting to pick the callback, so registering both is the way to go. See [Static OAuth for remote servers](https://cursor.com/docs/context/mcp#static-oauth-for-remote-servers).

If the warning persists after adding both, send the exact `redirect_uri` from Output → `MCP: <your server>` logs plus your provider name and I’ll dig in.

---

_[View the full topic](https://forum.cursor.com/t/mcp-oauth-callback-changed-to-http-localhost-8787-callback-and-authentication-still-fails/165752)._