Cursor Creating Hundreds of Thousands of MCP Oauth Clients

Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Starting around 5 days ago I noticed many hundreds of thousands of oauth dynamic client registrations coming from cursor across different customers.

I opened cursor locally and did not see this behavior. I then updated my own cursor locally and immediately saw it in an infinite loop of client registrations. Closing cursor caused it to stop, and after opening cursor again I could not get this to reproduce.

This sounds the same as this issue (MCP Server Race Condition Causes Infinite Process Spawning on Windows (Cursor 2.0.34) - #4 by KyleKolander) but I am on Mac so it’s not just a windows issue, it is something widespread.

Steps to Reproduce

Configure remote MCP connection that requires oauth credentials (but don’t connect).
Update cursor??

A less critical but maybe related version of this bug can be reproduced by simply adding and removing an MCP server repeatedly. Open mcp.json and remove an MCP server, save the file. Undo to add it back while looking at remove server logs. Cursor registers two oauth clients (instead of just one) around 50% of the time.

Expected Behavior

Only one oauth client is created. Additionally consider caching the oauth client rather than recreating it on every new authentication (so that each instance only creates one oauth client instead of dynamically creating a new one on every auth)

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.0.60
VSCode Version: 1.99.3
Commit: c6d93c13f57509f77eb65783b28e75a857b74c00
Date: 2025-11-05T00:50:54.645Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

2 Likes
2

Hey, thanks for the report. This is a known race condition and it’s already escalated to engineering.

Your report confirms it affects macOS too, not just Windows. Another user had to disable Cursor in their DCR flow due to thousands of registrations.

To help us prioritize a fix, could you share:

  • Approximate daily volume of registrations you’re seeing?
  • Number of customers/servers affected?
  • Is it still impacting you now, or was it only during the initial update?
3

I’ve seen over 670,000 registrations since the problem started (so averaging more than 100K per day), pretty much all due to this issue (daily registrations from next most popular MCP client is less than 100).

Our MCP server is in use by ~100 companies including many large fortune 500s - based on logs it looks like around 50 individual users are running buggy cursors version (that registered 1000 times or more), with the top user registering 113,000 times over a 48 hour period.

I was only able to reproduce this problem with my own cursor client on initial update, but it is still impacting our production systems - we had 60,000 client registrations over the past 24 hours

1 Like
4

Yup, the exact same thing is happening for us as well. Started happening since the 2.0 release.

5

This is the kind of problem that would impact enterprise-level MCP builders the most. If this is not fixed, people who are using Cursor seriously for enterprise use cases won’t enjoy the experience. Can someone from Cursor team help here?

1 Like