This is a known limitation – the browser automation MCP currently runs on the local UI host, and its tools don’t fully carry over to SSH remote sessions. Our team has previously acknowledged this and has been working on improving remote environment support (SSH, WSL, dev containers).
You can try this workaround – add the following to your User Settings (Cmd+Shift+P > “Preferences: Open User Settings (JSON)”):
This forces the browser automation extension to run on your local machine rather than the remote host. After adding it, restart Cursor and reconnect to your SSH session.
If the tools still aren’t available after that, could you check Settings > Tools & MCP > Browser Automation and make sure Browser Tab is selected and enabled? Then close the current chat and start a new one.
Thanks for trying that. Since you’re on an enterprise team, there’s an additional step needed – browser automation features are disabled by default for enterprise plans and need to be enabled by your team admin.
Once that’s done, restart Cursor and reconnect to your SSH session. Then make sure Browser Tab is selected in Cursor Settings > Tools & MCP > Browser Automation (you may need to close and reopen the current chat for changes to take effect).
Regarding your question about Chrome DevTools MCP – the built-in browser automation is the recommended path. Once your admin enables the feature, the remote.extensionKind setting you already added should allow it to use your local Chrome over SSH. A third-party Chrome DevTools Protocol MCP would face similar local-vs-remote challenges and would require additional setup.
I’ve only gotten this far because my enterprise team has already enabled it. So I’ve already made sure that Browser Tab is selected in the MCP settings section.
The setting you gave me works – browser automation extension is running on my local machine (as evidenced by a different IP address than my remote), but the MCP tools are still not working. I get this output from the agent:
The cursor-ide-browser MCP server is registered, but none of its browser tools (browser_tabs, browser_navigate, browser_snapshot, etc.) are currently exposed to me.
The extension running locally is confirmed (the IP difference shows it), so the remote.extensionKind setting is doing its job. The problem is one step further down the chain: the tools from the extension aren’t being propagated to the agent in the SSH session even though the server itself is registered.
This pattern (server registered, zero tools exposed) is a known issue we’re tracking. A couple of things worth trying while connected to SSH:
Toggle the browser automation off and on: Settings > Tools & MCP > Browser Automation, turn it off, wait a few seconds, turn it back on. Then start a new chat.
Reload the window: Cmd+Shift+P > “Developer: Reload Window”. Then start a new chat.
If neither helps, could you share the MCP output logs from an SSH session? This will help us narrow down the exact point where tool exposure breaks:
Connect to SSH
View > Output, then select MCP Logs (or cursor-ide-browser) from the dropdown
Start a new chat and ask the agent to use the browser
Thanks for the logs. They confirm the extension is activating correctly on your local machine — the MCP provider initializes and the browser UI script injects without errors.
The issue is one step further down: tools from the extension aren’t reaching the agent’s tool catalog. This matches a known regression in 3.1.17 that our team is tracking. The toggle and reload workarounds don’t resolve this particular pattern, unfortunately.
Once a fix ships, the remote.extensionKind setting you already have should make browser automation work over SSH. For now, browser automation is available from local (non-SSH) workspaces as a fallback.