Cursor-ide-browser MCP disconnects every ~5 minutes during heavy agent browser usage

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The cursor-ide-browser MCP server drops to status=error every ~5 minutes during continuous agent browser sessions, breaking the session with “MCP server does not exist: cursor-ide-browser”

Steps to Reproduce

  1. Open an Agent chat with cursor-ide-browser MCP enabled
  2. Run 15+ sequential browser_navigate / browser_click tool calls back-to-back (~5 min of continuous usage)
  3. The MCP disconnects mid-session with “MCP server does not exist: cursor-ide-browser”

Expected Behavior

The internal lease/heartbeat renews silently in the background without dropping tools to 0 or interrupting active tool calls.

Screenshots / Screen Recordings

cursor bug.png
cursor bug.png1630×272 14.2 KB

Operating System

MacOS

Version Information

IDE:
Version: 3.2.21
VSCode Version: 1.105.1
Commit: b347a855021632d9df326a4cc714e1afd6035d1bb8716fc12f986e8cefb6954b

For AI issues: which model did you use?

claude 4.6 sonnet

Additional Information

Log evidence from Mcp FileSystem Writer.log (~/…/anysphere.cursor-agent-exec/Mcp FileSystem Writer.log):

May 4 session:
11:29:10 - status=error, tools=0
11:30:02 - status=connected, tools=26 (auto-recovered)
11:35:00 - status=error, tools=0 (~5 min later, session broken)

May 1 session showing consistent ~5-min cadence:
11:11:50 - status=error
11:16:53 - status=error (+5:03)
11:22:10 - status=error (+5:17)

The trigger is cursor_mcp_lease_server_status firing with status=error. The server usually auto-recovers in 1-4 seconds, but any agent tool call landing in that window gets a hard failure. The lease should renew silently without dropping tools to 0.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

This is a regression. Prior to ~April 30, the cursor-ide-browser MCP had toolCount=33
and zero status=error events in logs. After a recent Cursor update, toolCount dropped
to 26 and the cursor_mcp_lease_server_status / cursor_mcp_lease_snapshot_store
lease mechanism appeared — along with the ~5-minute disconnect cycle.
The lease mechanism did not exist in the April 24 logs at all.

7

HI there,
This seems like a known issue on our side.

Your log analysis is spot-on, and the regression timeline (post-April 30) matches what we’re seeing. We’re actively tracking browser MCP reliability issues internally. I don’t have an ETA for a fix yet, but your detailed logs and timestamps here are helpful for our team.

In the meantime, if you hit the disconnect mid-session, starting a new chat should re-establish the connection immediately (since the server auto-recovers within seconds). Not ideal for long browser automation flows, but it should let you continue without restarting Cursor.

Let me know if the disconnects get worse or if you notice any pattern that helps you work around the timing.