I've been curious about how Claude's browser extension actually works under the hood. Specifically, how it lets external tools like Claude Code control the browser remotely. A few blog posts have already covered this well, but I wanted to go deeper on the mechanics and see how easy it would be to build my own client. Turns out, with an AI coding agent helping, the whole thing took no longer than 10 minutes.

Here's what I found, how it works across platforms, and some takeaways about what this pattern means for AI in the enterprise.

How Claude's Browser Extension Works

Anthropic's Claude browser extension operates in two modes. In standalone mode, it runs an autonomous agent inside a side panel, calling Claude's /v1/messages API with a rich set of browser tools. In collaborative mode, it exposes those same browser tools to external processes like Claude Code running on the same machine.

Both modes have been well-documented by the community. Weikang Zhang's teardown extracted the system prompt and all tool definitions, and AIPex's analysis explored the architecture and collaboration flow with Claude Code via Native Messaging. Paul Klein IV noted on X that the extension effectively acts as an MCP server. Claude Code connects as a client, and the 19 browser tools follow the MCP naming convention (mcp__claude-in-chrome__*). He also flagged the security implication: since the native host runs locally and any process can talk to it, a rogue website could potentially use prompt injection to extract personal data through the agent.

What I wanted to do was go hands-on: look into the binary itself, understand the exact protocol on the wire, and see how quickly I could build a working client that calls these tools programmatically on any site.

The Native Messaging Bridge

When you install Claude Code or Claude Desktop on a device, it registers a native messaging host, a local binary that any Chromium browser (Chrome, Edge, Island, Brave) can launch and communicate with over stdin/stdout. The extension connects to it using the registered name:

• com.anthropic.claude_browser_extension — shipped with Claude Desktop
• com.anthropic.claude_code_browser_extension — shipped with Claude Code

This binary does one job: bridge between the browser extension and local processes that want to use the browser tools. It listens locally — on macOS via a Unix domain socket at /tmp/claude-mcp-browser-bridge-<username>/<pid>.sock, and on Windows via a Named Pipe at \\.\pipe\claude-mcp-browser-bridge-<username>.

Any process on the machine can connect to this endpoint and start issuing tool commands. There is no authentication, no token exchange. Just connect and send.

The Protocol

The wire protocol is not standard MCP (Model Context Protocol). It's a simpler, proprietary format:

Transport: 4-byte little-endian length prefix + JSON body.

Request:

{
  "type": "tool_request",
  "method": "execute_tool",
  "params": {
    "tool": "navigate",
    "args": { "url": "https://example.com", "tabId": 123456 }
  }
}

Response:

{
  "result": {
    "content": [
      { "type": "text", "text": "Navigated to https://example.com" }
    ]
  }
}

No JSON-RPC envelope, no initialization handshake, no tool discovery endpoint. There's only one method: execute_tool. You connect, send a request, get a response. That's it.

Building a Client in 10 Minutes

I wanted to see how quickly an AI agent running on the endpoint could discover and use these tools. Using Cursor as my coding agent, the process looked like this:

1. Find the socket — glob for /tmp/claude-mcp-browser-bridge-*/*.sock, pick the one with a live PID
2. Discover the protocol — try a few message formats until we get a response (LE length-prefix worked)
3. Extract tools from the extension source — pull out all tool names defined in the extension's JavaScript, then verify each one against the live socket
4. Build a working MCP server — wrap the proprietary protocol in a standard MCP interface

Total time: about 10 minutes from "I wonder if I can talk to this socket" to a fully working MCP server.

By extracting tool name strings from the extension's source and testing each against the live socket, here's the complete set of tools available to any local process:

That's full browser automation: navigation, content extraction, form filling, file upload, arbitrary JavaScript execution, mouse/keyboard control via the computer tool, and network monitoring, all accessible from any local process, on any site the user has open.

Security Takeaways

This is well-engineered for its intended use case: a developer using Claude Code on their personal machine. But through an enterprise lens:

No audit trail. Tool calls execute with no logging visible to IT. The organization has no visibility into what pages were read, what data was extracted, or what actions were taken.

No data protection. get_page_text returns the full content of any page, including SaaS applications, internal tools, and sensitive documents. javascript_tool can execute arbitrary code in any page context. None of this passes through DLP. This works on any site the user has open, such as your CRM, your internal admin panels, your banking portal.

No policy enforcement. Every connected process gets the full tool set. There's no mechanism to restrict tools based on the destination site, data sensitivity, or calling process.

None of this is a vulnerability. It's working as designed for consumer use. But as AI agents become standard tools in the workplace, this pattern of "open local IPC with full browser access" is something enterprises need to think about.

How Island Approaches This

Island's Enterprise Browser exposes browser capabilities to AI agents through a built-in MCP server, but with enterprise governance at every layer.

Every MCP tool invocation is logged with full context: who initiated it, which agent made the call, which page was targeted, and what data was accessed. These events flow into your SIEM, giving security teams the same visibility into AI agent activity as they have over human users.

Island's DLP engine evaluates data flowing through MCP tool calls in real time. Before page content is returned to an agent, before form data is submitted — data protection policies apply. Sensitive content can be redacted or blocked, just as it would be for a human user.

Critically, policies are applied based on the full context: user identity and group membership, device posture and compliance state, the destination site (sanctioned app vs. unknown external site), and the specific tool being invoked. An agent might be permitted to read pages in Salesforce but not execute JavaScript. It might navigate to approved applications but not arbitrary URLs. It's not a binary allow/block. It's a policy matrix that can express rules like: "allow agents to read Salesforce data on managed devices for users in Sales, but block JavaScript execution and file uploads everywhere."

Browser-based AI agents are here. They read pages, fill forms, navigate applications, and execute workflows on behalf of users. The question for enterprises isn't whether to allow them. It's whether you have visibility and control when they do. Island was built for exactly this: AI capabilities operating inside the browser, with every interaction visible, governed, and protected.

Island AI Services delivers governed AI agents, embedded AI assistants, and complete visibility across every AI entry point — all inside the Enterprise Browser. Learn more at island.io/ai.

‍