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.
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.
Hey, thanks for the detailed report. The timeline with wb14/wb15 and the behavior breakdown really helped.
What you’re describing matches an issue we’re already tracking. The built-in browser tools can drop out of the live route while the registry still shows cursor-ide-browser as ready, which is why GetMcpTools and CallMcpTool don’t match and you get Server not found. I’ve shared your notes with the team.
As a workaround for now, reloading the window Cmd+Shift+P → “Reload Window” reliably brings the browser tools back.
One more thing. Your report shows the Cursor version as unknown. If you can check the exact version in Cursor → About / Help, that’ll help us tie this to a specific release.
I can’t share a fix timeline yet, but I’ll update the thread when I have news.
The fix for the case you described, where disposing the old workbench removes a newer cursor-ide-browser registration, has already landed and will ship in one of the next Cursor releases. Registrations now have per-instance ownership, so disposing an old instance won’t remove the active registration from the new one, and the ready state stays consistent with the live route in this case.
Also, thanks for the analysis and the suggested fix. The approach we shipped is basically what you described, using a registration token with compare-and-delete.
Until you’re on a version with this fix, the workaround Cmd+Shift+P then Reload Window still brings back the browser tools. Once you update, please try again and let me know if you can still reproduce it.
Still broken on 3.18.9 (Linux Ubuntu 24.04 x64, Glass). Adding a local-agent repro that matches this thread’s No browser view available and also explains the 30s “re-register” failure the agent sees.
Error the agent gets
Server not found: cursor-ide-browser (MCP provider did not re-register within 30000ms)
GetDynamicTools can still list cursor-ide-browser as namespaceStatus: ready (stale catalog). The next CallDynamicTool then waits 30s and dies. Retrying the same call burns another 30s.
Logs (every new Glass workbench today)
~/.config/Cursor/logs/20260902T083539/window1_wb*/…/1-Cursor IDE Browser Automation.log
On all 11 workbenches (wb0–wb10):
Cursor Browser Automation extension activated
Using Browser MCP provider
injectBrowserUIScript called
[ERROR] Failed to inject browser UI script:: No browser view available
at …/workbench.glass.main.js
On wb10 (created 09:52 local, same second as a move_agent_to_root abort):
Browser Automation MCP Provider disposed
After that dispose, browser MCP stays dead in the chat. Reproduced again at 10:08 by calling browser_tabs — same 30s re-register timeout, no new workbench.
Why it happens here
Glass + many workbenches in one Cursor window
move_agent_to_root (even when the destination folder is already in the multi-root workspace) spawns a new workbench
Extension activates before any Simple Browser view exists → inject fails once → provider disposed → no retry
Same race this thread already described; Reload Window is not a fix
Expected
If no browser view yet: keep the provider alive and inject when the first tab/view appears
Do not dispose after a single failed inject
Do not advertise tools as ready after dispose
Fail the tool in <1s, not after a 30s re-register wait
move_agent_to_root to an already-open multi-root folder must be a no-op (related: #169527)