macOS Glass: cursor-ide-browser stays Connected but browser_tabs hangs indefinitely (hours) across 3.20.21–3.21.13

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

  • MCP & tools
  • Cursor IDE Browser / Glass Browser Tab (cursor-ide-browser)

Describe the Bug
The built-in Browser Tab MCP server reports connected (catalog ready, 16 tools) but agent tool calls such as browser_tabs with action: "list" never return. There is no client timeout. Calls have stayed in-flight for hours until the user cancels them or the Browser Automation MCP provider is disposed.

This is not a network or OS issue. It is a Cursor browser-automation lifecycle / guest-webview IPC bug. It has persisted for 1–2 weeks through multiple Cursor updates and machine reboots.

This is related to, but not the same as, the 30s “MCP provider did not re-register” / stale-catalog reports. Here the namespace stays ready and the call simply never completes.

Steps to Reproduce

  1. macOS, Cursor Glass layout, Browser Automation enabled, using the built-in Browser Tab (not an external Chrome target).
  2. Open an Agent chat. Confirm cursor-ide-browser is listed as connected / namespaceStatus: ready with the usual browser tools (browser_tabs, browser_navigate, browser_snapshot, …).
  3. From the agent, call browser_tabs with action: "list" (no other arguments required).
  4. Optionally leave the call running; do not cancel immediately.

Expected Behavior
browser_tabs returns the open Browser Tab list, or fails fast (seconds, or at most the documented ~30s re-register timeout) with an error the agent can handle.

Actual Behavior

  • Tool call hangs with no completion, no error, no timeout.
  • Cancelling is the only way to unblock the agent (one observed hang lasted ~2 hours 10 minutes, ~15:53–18:03 local, until provider dispose/cancel).
  • After cancel/dispose, later calls in the same window often hang the same way until Developer: Reload Window.
  • Meanwhile MCP status continues to say connected.
  • Screenshot/helper path also fails with Browser view not found even when a Browser Tab exists.

Screenshots / Screen Recording
Not attached. This is an IPC hang, not a visual glitch. Log signatures below are sufficient to match internally.

Operating System

  • macOS 27.0 (Darwin 27.0.0), build 26A428
  • darwin-arm64

Version
Current (still reproducing):

Cursor 3.21.13 (stable)
Commit: e44a49c17e334d442e58bbde931d791200f014a0
Date: 2026-09-18T06:43:24.799Z
Electron: 42.10.0
OS: Darwin arm64 27.0.0
Layout: glass

Also reproduced on the same machine after updates, with the same log signatures:

  • 3.20.21
  • 3.21.9
  • 3.21.13 (current)

Log sessions spanning 2026-09-15 through 2026-09-19 (multiple app launches / reboots / updates). Reproduced on two independent --user-data-dir profiles (default Cursor profile and a second isolated profile).

For AI issues: which model did you use?
Any agent model. This is a local MCP/tool-runtime hang, not a model-quality issue.

For AI issues: add Request ID with privacy disabled
Request ID from a hung browser_tabs call that was later cancelled:

142c571a-508a-4069-83a5-d9c71d0129dc

Please treat this as a tool-runtime hang, not an agent-behavior/content issue. I am not attaching prompts, code, paths, or conversation content.

Additional Information

Why this is Cursor, not the host OS

  • The Browser Tab UI can still exist while automation IPC is dead.
  • cursor-ide-browser remains advertised as connected (toolCount: 16, status connected) while calls never complete.
  • Failures are in Cursor’s own renderer / Browser Automation extension, not in page JS or DNS.

Recurring log signatures (redacted paths only)

From ~/Library/Application Support/Cursor/logs/ (renderer + 1-Cursor IDE Browser Automation.log):

[WebviewBrowserManager] Guest webview dead for glass-browser-<uuid>, recreating
Error invoking remote method 'GUEST_VIEW_MANAGER_CALL': reply was never sent

command 'mcp.onBrowserConnectivityChanged' not found
    at …/workbench.glass.main.js

Failed to inject browser UI script:: No browser view available
Browser Automation MCP Provider disposed

Failed to update screenshot service: Error: Browser view not found

[MCPService] Server status update: cursor-ide-browser -> connected
[MCPService] Received snapshot for cursor-ide-browser  status=connected toolCount=16
[MCPService] Skipping createClient for already-connected server: cursor-ide-browser

Counts from local logs over this window (same machine, multiple sessions):

  • Browser Automation MCP Provider disposed: 182 Browser Automation log files
  • No browser view available: 6 files
  • Browser view not found: 8 files
  • Guest webview dead / reply was never sent: burst of 13 lines in a single renderer.log (2026-09-19 ~02:56), all for the same glass-browser-* id
  • mcp.onBrowserConnectivityChanged not found: repeated in renderer.log on 2026-09-17, 2026-09-18, and 2026-09-19

Cold-start pattern: extension activates → inject fails with No browser view available → MCP still marked connected → later Provider disposed → agent call either 30s-misses or, in this bug, hangs with no timeout.

Aggravating conditions

  • Glass layout
  • Long-lived Cursor window with many workbenches / renderer processes
  • Multiple Agent chats / subagents that all try to own cursor-ide-browser
  • Calling browser tools when no Browser Tab view has been created yet (inject-before-view race)
  • Overloaded Cursor process (high renderer count / CPU) makes the hang more likely but is not required

What does not fix it

  • Updating Cursor (seen on 3.20.21 → 3.21.9 → 3.21.13)
  • Rebooting macOS
  • Starting a new Agent chat in the same window (catalog still “ready”, calls still hang)
  • Waiting (no timeout)

Workaround (partial)

  1. Cancel the hung tool after ~20s (do not wait; there is no timeout).
  2. Command Palette → Developer: Reload Window.
  3. Keep a single agent as the browser-tool owner; open a Browser Tab before the first automation call.

Reload is not durable. The hang returns in the same session/day after further use.

Related public reports (same subsystem, different failure mode)

Please do not close this as a duplicate of the 30s re-register bug without checking the hang-forever path. Related Bug Reports topics (no URLs; this is a new account with a 2-link limit):

  • Topic 170312 — Linux Glass: cursor-ide-browser MCP disposed after No browser view — 30s re-register timeout
  • Topic 168965 — Stale cursor-ide-browser provider disposal removes newer registration and leaves MCP catalog ready
  • Topic 169858 — cursor-ide-browser MCP missing from Agent chats even when Browser Tab is connected

Staff previously noted a provider-registration ownership fix. That does not cover this case: on 3.21.13 the server still shows connected and browser_tabs never returns.

Suggested fix

  • Never advertise cursor-ide-browser as ready/connected after a failed inject or dead guest webview.
  • Fail tool calls in <1s (or at most 30s) when the guest view is dead / GUEST_VIEW_MANAGER_CALL gets no reply; do not hang the agent.
  • Keep the MCP provider alive until a Browser Tab exists, then inject; do not dispose after a single No browser view available.
  • Rebind mcp.onBrowserConnectivityChanged so Glass workbenches do not log command not found.
  • Recreate a dead glass-browser-* guest webview once, not in a tight reply was never sent loop.

Does this stop you from using Cursor?

  • Sometimes — I can sometimes use Cursor. Agent browser automation is unreliable for 1–2 weeks and through several updates; other Cursor features still work.
6

Hey @Avaz, thanks for the detailed report, and for separating this from the 30 second re-register case. You are right that it is a different failure: the provider stays registered, but a browser tab whose page renderer has stopped responding can hold the tool call open with no deadline, and browser_tabs touches every open tab, so one bad tab stalls the whole list.

This is a known issue we are already tracking, and I have added your report (macOS 27, 3.20.21 through 3.21.13, the multi-hour hang) to it.

In the meantime, two things help more than a plain reload:

  1. When a call hangs, cancel it, then close the Browser tabs you are not using (especially any that have been sitting in the background for a long time) before retrying. A single unresponsive tab is enough to block browser_tabs.
  2. Run Cmd + Shift + P > Reload Window only if the hang persists after that.

One thing that would help us pin it down: next time a browser call hangs, before you cancel it, run Cmd + Shift + P > Capture and Send Debugging Data from the Command Palette and paste the debugging ID here (or attach the zip if it saves locally). That capture includes the browser view state at the moment of the hang, which is exactly what we are missing.

8

Hey Colin — thanks. That matches what we see.

browser_tabs is shared across every agent/workbench in the same Cursor Agents window, not per chat and not per project. Hangs showed up in chats that had no Browser panel open; the blocking tab belonged to another workspace in the same window.

We have now closed every Cursor Browser tab across all projects. The shared list is empty.

We do not have a hang in progress, so no debugging capture yet. Next time a browser call hangs, I will run Capture and Send Debugging Data before cancelling and paste the ID here.

9

I am getting the same.