# macOS Glass: cursor-ide-browser stays Connected but browser\_tabs hangs indefinitely (hours) across 3.20.21–3.21.13 **URL:** \ **Category:** Bug Reports\ **Tags:** mcp, browser, agents-window\ **Created:** [September 19, 2026, 1:14pm UTC](https://forum.cursor.com/t/macos-glass-cursor-ide-browser-stays-connected-but-browser-tabs-hangs-indefinitely-hours-across-3-20-21-3-21-13/172347 "2026-09-19T13:14:10Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Avaz](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Avaz](https://forum.cursor.com/u/Avaz)\ **Post date:** [September 19, 2026, 1:14pm UTC](https://forum.cursor.com/t/macos-glass-cursor-ide-browser-stays-connected-but-browser-tabs-hangs-indefinitely-hours-across-3-20-21-3-21-13/172347/1 "2026-09-19T13:14:10Z")
**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): ```auto 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`): ```auto [WebviewBrowserManager] Guest webview dead for glass-browser-, recreating Error invoking remote method 'GUEST_VIEW_MANAGER_CALL': reply was never sent ``` ```auto command 'mcp.onBrowserConnectivityChanged' not found at …/workbench.glass.main.js ``` ```auto Failed to inject browser UI script:: No browser view available Browser Automation MCP Provider disposed ``` ```auto Failed to update screenshot service: Error: Browser view not found ``` ```auto [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. ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [September 19, 2026, 3:32pm UTC](https://forum.cursor.com/t/macos-glass-cursor-ide-browser-stays-connected-but-browser-tabs-hangs-indefinitely-hours-across-3-20-21-3-21-13/172347/6 "2026-09-19T15:32:29Z")
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. ---
**Author:** ![Avaz](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Avaz](https://forum.cursor.com/u/Avaz)\ **Post date:** [September 21, 2026, 10:27am UTC](https://forum.cursor.com/t/macos-glass-cursor-ide-browser-stays-connected-but-browser-tabs-hangs-indefinitely-hours-across-3-20-21-3-21-13/172347/8 "2026-09-21T10:27:11Z")
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. ---
**Author:** ![Ian\_Robertson](https://avatars.discourse-cdn.com/v4/letter/i/8baadc/32.png) [@Ian\_Robertson](https://forum.cursor.com/u/Ian_Robertson)\ **Post date:** [September 21, 2026, 10:22pm UTC](https://forum.cursor.com/t/macos-glass-cursor-ide-browser-stays-connected-but-browser-tabs-hangs-indefinitely-hours-across-3-20-21-3-21-13/172347/9 "2026-09-21T22:22:50Z")
I am getting the same.