Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Summary
The built-in cursor-ide-browser MCP provider can become unroutable while its cached MCP catalog still reports the server as ready and exposes its schema. GetMcpTools reports ready/schema, but CallMcpTool returns “Server not found”. Investigation indicates that disposal of an older workbench provider registration can remove a newer registration sharing the same provider ID.
Steps to Reproduce
Reproduction steps
- In Cursor, open one project and an Agent chat that uses the built-in IDE browser.
- Trigger browser tool operations that materialize two separate temporary workbench instances (anonymized here as wb14 and wb15), each registering the same cursor-ide-browser provider ID.
- Allow the older workbench (wb14) to reach zero workspace references and stop with context no-refs.
- Observe wb14 dispose/unregister cursor-ide-browser while wb15’s provider object is still alive.
- Call GetMcpTools for cursor-ide-browser: it still reports ready and returns the tool schema.
- Immediately call a browser tool through CallMcpTool: it fails with “Server not found: cursor-ide-browser”.
Expected Behavior
Expected behavior
Disposing an older provider instance must not unregister a newer active registration with the same logical ID. Provider registry state and the MCP catalog/lease snapshot should be invalidated atomically. A ready status should mean that a health-checked execution route exists.
Operating System
MacOS
Version Information
Cursor version: unknown
Observed: 2026-08-20
OS: macOS 14.6 / Darwin 23.6.0
Additional Information
Actual behavior
After the older instance was disposed, cursor-ide-browser disappeared from the live execution route even though the newer provider remained alive. The catalog continued to report ready/schema, producing a split-brain state: GetMcpTools succeeded while CallMcpTool returned “Server not found”.
Evidence timeline
- 19:54:41.884: the older wb14 Browser Automation MCP Provider was disposed; its workbench then stopped due to context: no-refs.
- 19:54:41.885: cursor-ide-browser was unregistered/removed.
- wb15’s provider remained alive until 20:01:40, but the execution route had already been lost at 19:54:41.
- The evidence does not identify which upper-layer UI, Agent, or tool object released wb14’s final workspace reference. Logs establish the no-refs terminal state, but do not contain the acquire/release owner or call stack.
Suspected root cause
Investigation of the locally installed application bundle indicates that provider registration uses a shared provider map equivalent to set(id, provider), while unregistration uses delete(id). It appears to lack an instance-identity or generation-aware compare-and-delete check. Therefore, if wb15 overwrites wb14 under the same ID, later disposal of wb14 can delete the map entry currently pointing to wb15. This is a suspected mechanism from local package analysis, not a claim about intended official source behavior.
Suggested fix
- Return an instance/generation registration token and use compare-and-delete during unregistration.
- Namespace internal provider IDs by window/workbench/agent, or maintain per-owner registrations and route explicitly.
- Atomically invalidate the catalog, lease snapshot, schema, and ready state when the live provider route is removed.
- Require a lightweight live registry health check before reporting ready.
Privacy note
All workbench names are anonymized instance labels. This report intentionally excludes usernames, local paths, workspace names, conversation IDs, account/job data, credentials, cookies, tokens, and full local logs. No local files are attached.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor