MCP OAuth callback 404 on localhost:8787 after Allow (Slack + Gmail plugins)

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Product area: Grok Bot / Cursor Plugins (MCP connectors) — Slack and Gmail marketplace plugins

Connecting Slack or Gmail MCP plugins fails at the end of OAuth. The Slack/Google Allow/consent page loads and succeeds, but the redirect back to Cursor’s local callback returns HTTP 404:

http://localhost:8787/callback?code=…

Browser shows:
Error response
Error code: 404
Message: File not found.
Error code explanation: 404 - Nothing matches the given URI.

Reproduced for:

  1. Slack plugin (marketplace plugin id 674 / user-Slack)
  2. Gmail plugin (account label victory-fits / user-Gmail)

Full quit of Cursor (Cmd+Q) and reconnect did not fix it. Same failure mode for both providers, so this looks like Cursor’s MCP OAuth callback listener on port 8787, not Slack/Google themselves.

Related prior reports: MCP OAuth 404 (forum topic about HTTP 404 token exchange / wrong URL), Slack MCP OAuth token exchange failures after Allow.

Steps to Reproduce

  1. In Grok Bot / Cursor, install Slack or Gmail plugin if needed.
  2. Click Authenticate / Connect for the connector.
  3. Complete Allow/consent in the browser for the workspace/Google account.
  4. Observe redirect to http://localhost:8787/callback?code=… returns 404 File not found.
  5. Connector remains needsAuth; tools stay unavailable.

Expected Behavior

After Allow, localhost:8787/callback should complete the OAuth code exchange and mark the connector connected.

Operating System

MacOS

Version Information

Latest Cursor on macOS as of 2026-08-11 (exact About string not captured)

Additional Information

  • Happens consistently (not intermittent) for this user as of 2026-08-11
  • Gmail path used a labeled account “victory-fits”
  • Browser workaround (signing into Gmail in the box browser) works; connectors remain broken
  • Please treat as Cursor MCP OAuth callback / token-exchange infra bug
  • OS: macOS (user machine); Grok Bot computer/box involved in auth card flow

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. It really helped with debugging.

The clue is in the error text: “Error response / Error code: 404 / Message: File not found. / Nothing matches the given URI.” This is not a Cursor page, it is the default error page from Python http.server. That means port 8787 on your Mac is already taken by another local process, and after you click Allow the redirect goes to that process instead of Cursor’s callback listener. That’s also why Cmd+Q didn’t help. The port is held by a third party process, not Cursor.

Workaround:

  • Find what’s listening on port 8787:
    lsof -nP -iTCP:8787 -sTCP:LISTEN
  • Stop that process. It’s often python3 -m http.server, a Dask dashboard, or wrangler dev since they default to 8787.
  • Click Authorize for Slack or Gmail again. The port is only needed during the handshake, after that you can use it again.

This is basically the same fixed port 8787 redirect behavior we’re tracking. It has come up in other threads too: Cursor OAuth redirect_uri uses fixed localhost:8787 port, OAuth redirect URI changed from cursor:// to http://localhost for Streamable HTTP MCP. I can’t share an ETA yet, but I’ll post here when there’s an update.

Let me know if the workaround helped.