BrowserMCP browser_click times out: "WebSocket response timeout after 30000ms"

5 answers

• Best answerAgentArmorHQ teamTeam4d ago

  Status: still open. As of this thread, the BrowserMCP repo had no commits since 24 April 2025, so don't expect a fix from the extension itself.

  The diagnosis that explains the thread (comment 9): this is not a click bug. The extension's MV3 service worker holds the WebSocket to the local MCP server. Chrome evicts the worker after roughly 30 seconds idle, the socket dies with it, and the next browser_click waits the full 30 seconds for a reply that never arrives — hence "WebSocket response timeout after 30000ms". Reading tools (browser_navigate, screenshot, get_console_logs) keep working because they are answered from the page context, not from the worker. That matches what everyone saw: the cursor visibly moves, but the click never lands. The "A listener indicated an asynchronous response... message channel closed" error is the same eviction.

  What worked for one user: run the extension with Chrome Canary instead of Chrome (comment 7, "Works for me!").

  If you stay on Chrome, there is no configuration that fixes it — Chrome decides worker lifetime. The usual mitigation is a keepalive alarm every ~20s so the worker doesn't idle out, but Chrome can still terminate it under memory pressure, so the failure can return.

  One commenter also maintains an alternative MCP browser extension that keeps the socket in an offscreen document to avoid the eviction; nine of thirteen tool names match, so switching config is mostly a one-line change. General advice: review the permissions and source of any third-party extension before granting it browser access, since it will be able to read and control your pages.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @yangsi7 tried on GitHub (Worked)

  Switched from Chrome to Chrome Canary with the same setup. Reported as "Works for me!"

  Source: https://github.com/BrowserMCP/mcp/issues/115#issuecomment-3287713457 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @GLouv tried on GitHub (Partly worked)

  Diagnosed the root cause as Chrome evicting the MV3 service worker mid-message, killing the WebSocket. Suggested the usual keepalive-alarm-every-20s workaround but noted Chrome can still kill the worker under memory pressure, so failures can return.

  Source: https://github.com/BrowserMCP/mcp/issues/115#issuecomment-5742935398 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @nilh2a2 tried on GitHub (Didn't work)

  In Claude Code, called browser_click on example.com, google.com and httpbin.org with explicit element refs. Every call returned "WebSocket response timeout after 30000ms", plus one "page keeping the extension port is moved into back/forward cache" error; screenshots confirmed the browser was alive.

  Source: https://github.com/BrowserMCP/mcp/issues/115#issuecomment-3238900581 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What a GitHub user tried on GitHub (Didn't work)

  Fresh install on Mac M1 with Chrome and Cursor. Ran the default prompt 'Go to google.com and search for "Browser MCP"'; the click/search failed and the LLM fell back to browser_navigate. get_console_logs and screenshot worked and the cursor moved, but no click registered.

  Source: https://github.com/BrowserMCP/mcp/issues/115 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport