With Browser Automation set to Browser Tab, the agent context / MCP catalog can advertise cursor-ide-browser (and ~/.cursor/projects/<ws>/mcps/cursor-ide-browser/ can briefly show tool descriptors with toolCount=16), but CallMcpTool / GetMcpTools({server:"cursor-ide-browser"}) fail with:
Error: MCP server "cursor-ide-browser" not found. Available servers: cursor-app-control, plugin-…, user-…
Split-brain in the same session: pattern catalog can report serverStatus=ready while direct calls fail. Toggling Browser Automation Off→On does not restore tools to an existing agent chat (new chat sometimes works). Reproduced on first browser use in home/empty-window and again from a project workspace — not only after long automation.
Steps to Reproduce
Open Agent chat (home/empty-window or project workspace) on Cursor 3.13.21
Observe CallMcpTool fails with MCP server “cursor-ide-browser” not found while other MCP servers remain available
Optionally: watch Mcp FileSystem Writer logs show join/leave lease with toolCount=16 then “left the lease”
Toggle Browser Automation Off then On again — existing chat still has no cursor-ide-browser
Expected Behavior
If cursor-ide-browser is advertised to the agent (prompt + disk catalog), CallMcpTool should succeed. Catalog discovery and runtime registration must not disagree. Toggling Browser Automation should refresh the current agent session (or clearly require a new chat).
Operating System
MacOS
Version Information
IDE:
Version: 3.13.21
Commit: 55434bd8062ece6fee083b82beed2aee42d253f0
OS: Darwin arm64 25.5.0
Brave is system browser.
For AI issues: which model did you use?
Cursor Grok 4.5
For AI issues: add Request ID with privacy disabled
N/A — failure is MCP routing / Browser Automation wiring (“server not found” / wrong tab), not a model completion error.
Why a new report: closest threads cover mid-session ~5min lease drops (/t/159736), zero tools while connected (/t/158762), or older access issues (/t/150919). This is cold-start / catalog-vs-runtime on 3.13.21, including toggle not refreshing an existing chat.
Privacy Mode / data sharing is on. Attaching sanitized local logs that show the catalog/disk vs runtime gap for this report.
What the logs show (catalog side)
On empty-window workspaceId=b23abea01bc4771017b008369920af3f, MCP FileSystem Writer repeatedly:
Writes cursor-ide-browser with toolCount=16 (catalog looks healthy)
Then Server "cursor-ide-browser" left the lease, scheduling directory removal
Re-adds with toolCount=16 again — churn throughout the morning (07:00–07:20 local)
While that catalog churn is happening, agent CallMcpTool still returns MCP server "cursor-ide-browser" not found in the agent runtime (this thread’s primary bug).
Extra signal in project writers (workspaceId=c63b395f…): ENOENT writing cursor-ide-browser~staging under a different project path (…/stocktextalerts-sfeo/…) — disk catalog write targeting the wrong workspace.
Session / identity (data sharing on)
machineId:45f9fb3f-e7a9-4793-a235-3a7bb93e4e3f
Cursor: 3.13.21 (55434bd8062ece6fee083b82beed2aee42d253f0) Darwin arm64
This is a real bug on our side (not your setup), and it’s a known class we’ve been tracking. The short version: the cursor-ide-browser server can be advertised in the catalog and on disk while the live registration the agent actually calls into transiently drops it at submit time. The catalog/disk state and the live-runtime state can legitimately diverge for short windows, which is why CallMcpTool fails while everything on disk looks healthy.
Two things that should unblock you today:
Reload the window (Command Palette → Developer: Reload Window). This has consistently restored the live registration on this class of report. As you noted, toggling Browser Automation Off→On isn’t reliable for an existing chat — a full reload is.
If the tools come back but the browser view feels stale after sleep/wake or a long session, call browser_navigate with newTab: true as the very next action. That forces the underlying browser view to rehydrate rather than reusing a stale view ID.
I’ve reported your case (with logs and the cold-start pattern) to our team.
Two quick asks if you hit this again after a reload:
Does browser_navigate with newTab: true (as the very first browser call) succeed, or does it also fail with server-not-found?
If it fails, does the file ~/Library/Application Support/Cursor/logs/<session>/window*/Mcp FileSystem Writer.workspaceId-<id>.log show lease returned 0 tools across 0 clients at the moment of the failing CallMcpTool, or is the lease showing tools but CallMcpTool still fails?
Either answer helps localize whether the fix in review will resolve your specific flavor.
14:49:57.882 — Server "cursor-ide-browser" left the lease, scheduling directory removal
lease then 179 tools across 9 clients (browser gone, other MCPs still present)
Later (14:55:04) browser sometimes reappears with toolCount=16, then drops again later
Cursor is also mentioning there is a lot of browser tool churn: 2309cursor-ide-browser left the lease events in this log session folder.
Happy to provide more info if that will help, thanks!
Hey @Rohan_Kanjani - thanks for the logs. This is on our side, not your setup, and it’s an issue we’re tracking. No timeline yet, but I’ll post here when there’s an update.
Since a reload isn’t holding for you, try these:
Fully quit and relaunch Cursor (Cmd+Q, not just Reload Window), then wait ~10s before opening an agent chat. Your chats and settings are preserved.
Make browser_navigate with newTab: true your first browser action - it forces a fresh view and sometimes makes the tools stick when a reload doesn’t.
Two quick things that’d help me pin down your case:
Which Cursor version and OS, and did it start after a recent update?
Does newTab: true as the first call succeed, or still fail?
Hit this again in a home/empty-window agent chat after the prior advice. Answers to your two asks:
1) browser_navigate with newTab: true as the first browser call?
Fails with server-not-found. Exact agent error (~15:47 local):
Error: MCP server does not exist: cursor-ide-browser. Available servers: cursor-app-control, plugin-aws-serverless-aws-serverless-mcp, plugin-supabase-supabase, plugin-svelte-svelte, plugin-vercel-vercel, user-Astro docs, user-cloudflare-docs, user-family-memory
Same turn: GetMcpTools({pattern:'cursor-ide-browser|browser_navigate'}) returned zero matches. So newTab: true never gets a chance to rehydrate a view — the server isn’t in the live registration the agent calls into.
2) Lease empty vs tools present at failing CallMcpTool?
Lease showing tools, but cursor-ide-browser already left (your second option). Immediately before the failing call (Mcp FileSystem Writer.workspaceId-be144a62…, window1_wb43):
15:43:34 — lease returned 128 tools across 9 clients; adds cursor-ide-browser toolCount=16
15:44:45 — lease returned 112 tools across 8 clients
15:44:45 — Server "cursor-ide-browser" left the lease, scheduling directory removal
15:44:45 — Incremental write removes cursor-ide-browser; totalServerCount=8 (other MCPs remain)
Also seeing Rohan-style empty-lease blips earlier in the same session folder (lease returned 0 tools across 0 clients → brief recover with toolCount=16 → leave again). Session 20260807T093902 counts: 144cursor-ide-browser left the lease, 47lease returned 0 tools across 0 clients.
Env
Cursor 3.15.6 (a1f686545fd0ce8917bbd2449f733551a9bce420) Darwin arm64 — upgraded since the original 3.13.21 report; still repro
Thanks, that pins it. This is coming from our side, not your setup, and it’s an issue we’re tracking. Your logs show the version where the browser server leaves the session and isn’t re-added, so newTab: true has nothing to call into. No timeline yet, but I’ll post here when there’s an update.
Best reset while it’s open, since a Reload isn’t holding for you:
Fully quit with Cmd+Q (not just Reload Window) - chats and settings are preserved.
Wait ~10s, then confirm the Browser panel shows connected before the agent’s first browser call.
Start a fresh chat after that - it has the best odds of the server staying registered for the session.
If it still drops mid-session, there’s no reliable in-session recovery today (reload, toggling Browser Automation, and newTab: true won’t rescue an already-emptied session), so relaunch + fresh chat is the cleanest path for now. Your logs were exactly what I needed, so no need to grab another slice right now.