Back to Blog

How to Give Your AI Agent a Real Browser: Chrome DevTools MCP Setup

Stop using headless sandboxes that get bot-detected instantly. Connect your AI to the Chrome you already use — with your cookies, sessions, and identity.

DV

Dzianis Vashchuk

7 min read

If you have ever tried to give an AI agent browser access, you have run into the same wall: most setups give the AI a headless sandbox that immediately gets flagged as a bot, can't log into anything useful, and resets its session on every run.

The pattern that actually works is different. Instead of a separate AI-controlled browser, you connect the AI to the browser you already use — with your cookies, your sessions, and your identity already in place.

This guide walks through the exact setup: Chrome DevTools MCP, how it works, and how OpenClaw uses it so your AI agent has a real, persistent browser session.

Why headless Chrome fails for real tasks

Headless Chrome sounds like the obvious solution. It's fully automated, scriptable, and cheap to spin up.

In practice, three things go wrong immediately:

Anti-bot detection. Major sites — Google, LinkedIn, Twitter, Amazon — fingerprint browser environments. Headless Chrome has dozens of tells: missing GPU metrics, empty plugin lists, unusual User-Agent strings, and timing patterns that don't match real users. Detection happens before your first page interaction.

No authenticated sessions. Headless Chrome starts fresh. Every session begins logged out. Sites that require login — which is most of the useful ones — need you to re-authenticate every run, and many block automated logins entirely.

Ephemeral state. Nothing persists. Tabs, cookies, form state, scroll position — all gone when the process exits. Multi-step tasks that span more than one browser session are nearly impossible to build reliably.

What Chrome DevTools Protocol (CDP) actually gives you

CDP is the native debugging interface built into Chrome. It's what developer tools use when you inspect elements, set breakpoints, or record a network trace.

Every Chrome instance exposes a local CDP endpoint at http://localhost:9222 (by default). Any process that can reach that endpoint can:

  • Navigate tabs
  • Click elements
  • Fill and submit forms
  • Read page content (DOM, text, screenshots)
  • Intercept and replay network requests
  • Access the JavaScript console

The critical property: the Chrome instance is still the real Chrome running on your machine. It has your profile, your cookies, your extensions, and your full browsing history. The AI is connecting to your browser — not running a separate isolated one.

Chrome DevTools MCP: the bridge from AI to your browser

MCP (Model Context Protocol) is an open standard that lets AI models call external tools in a structured way. OpenClaw uses it to give your AI a defined set of browser actions — click, type, navigate, screenshot, read DOM — that it can call through your real Chrome session.

The setup from OpenClaw's side:

  1. @vibebrowser/chrome-devtools-mcp runs as a local process on your machine.
  2. It connects to Chrome via http://localhost:9222.
  3. It exposes browser actions as MCP tools to your AI agent in OpenClaw.
  4. OpenClaw, running in the cloud, routes tool calls through a Tailscale tunnel to your local MCP server.

The result: your AI agent makes tool calls that control your local Chrome. No fingerprint changes. No new browser. Your existing sessions work.

Step 1: Enable CDP in Chrome

Chrome must be running with CDP enabled. Launch Chrome with:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/.chrome-devtools-mcp"

On Windows:

"C:\Program Files\Google\Chrome\Application\chrome.exe" ^
  --remote-debugging-port=9222 ^
  --user-data-dir="%USERPROFILE%\.chrome-devtools-mcp"

Verify it's working:

curl http://localhost:9222/json

You should see a JSON list of open tabs. If you get Connection refused, Chrome isn't running with the flag.

Note: A separate --user-data-dir means this Chrome instance has its own profile. If you want the AI to access your main profile's cookies and sessions, point to your real profile directory — but be aware Chrome can only run one instance per profile. Most users run a dedicated profile for AI access.

Step 2: Install chrome-devtools-mcp

npx -y @vibebrowser/chrome-devtools-mcp

That's it. The npx invocation downloads and runs the MCP server, connecting to Chrome at localhost:9222.

To make it persistent (runs in the background without keeping a terminal open):

# macOS: create a Launch Agent
cat > ~/Library/LaunchAgents/com.vibebrowser.chrome-mcp.plist << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>com.vibebrowser.chrome-mcp</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/npx</string>
    <string>-y</string>
    <string>@vibebrowser/chrome-devtools-mcp</string>
  </array>
  <key>RunAtLoad</key><true/>
  <key>KeepAlive</key><true/>
</dict>
</plist>
EOF

launchctl load ~/Library/LaunchAgents/com.vibebrowser.chrome-mcp.plist

Step 3: Connect to OpenClaw via Tailscale

OpenClaw's AI agent runs in the cloud. To reach your local MCP server, OpenClaw uses Tailscale — a private mesh network that creates a secure tunnel between your machine and your OpenClaw tenant.

Install Tailscale (if you haven't):

# macOS
brew install tailscale
open -a Tailscale

# Linux
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

In your OpenClaw tenant (via Telegram):

/config browser tailscale

OpenClaw walks you through linking your Tailscale account. Once linked, your AI agent can reach your local chrome-devtools-mcp server through the Tailscale mesh, even when you're not on the same network.

Step 4: Verify the connection

From Telegram, send your OpenClaw agent:

Take a screenshot of the current browser tab

If everything is connected, you get a screenshot back in Telegram within a few seconds. Your AI is now looking at what your Chrome is showing.

From there, you can give real browser instructions:

Go to github.com/myorg/myrepo and summarize the last 5 issues

Open my Google Analytics dashboard and tell me which pages had the most traffic this week

Go to LinkedIn and find the profile page for [name], then extract their current title and company

All of these work because the AI is using your real Chrome with your sessions.

Why this beats browser extensions

A Chrome extension runs inside Chrome as a browser-side script. It can read page content, inject scripts, and intercept requests — but it can't run long autonomous tasks, maintain conversation context, call external LLMs with memory, or coordinate multi-step workflows across many sites.

Chrome DevTools MCP + OpenClaw works the other way around: the AI agent is the orchestrator, and the browser is one of its tools. The agent maintains full context, calls the browser when needed, and does everything else (summarizing, writing, reasoning, sending notifications) in its own runtime.

The result is a qualitatively different level of capability: tasks that would require a human to click through dozens of pages over 30 minutes can be delegated to the agent, which reports back in Telegram when it's done.

The browser profile question

OpenClaw supports two browser profiles in its cloud runtime:

  • openclaw — an isolated browser with no personal data. Safe for anonymous browsing, public-site extraction, and anything you don't want touching your personal sessions.
  • user — connects to your real Chrome session (via CDP + Tailscale). Used for tasks that need login access.

For most power users, the pattern is:

  • Use openclaw for research and public-site tasks
  • Switch to user for anything that requires authentication

You can set the default per task with /browser user or /browser openclaw in Telegram.

Troubleshooting

curl http://localhost:9222/json returns empty or connection refused

Chrome isn't running with --remote-debugging-port=9222. Check your launch command. On macOS, if you're launching Chrome from the Dock, the flag isn't applied — you need to launch from the terminal or a script.

MCP server connects but AI gets no response from browser

Check that the Tailscale tunnel is active on both ends. Run tailscale status and confirm your machine appears in the list with a green status. If not, tailscale up to reconnect.

Screenshots arrive but are blank or show the wrong tab

chrome-devtools-mcp attaches to the frontmost tab by default. Switch to the tab you want the AI to control before issuing commands, or use the select_page tool to specify a tab by URL.

Google blocks login inside the openclaw cloud browser

This is expected. Google detects cloud Chrome environments and blocks login. For any task that needs a Google account — Gmail, Drive, Analytics, Calendar — use the user profile (your local Chrome via CDP) instead.

Summary

The working setup for real browser automation:

  1. Chrome running with --remote-debugging-port=9222 on your machine
  2. @vibebrowser/chrome-devtools-mcp connecting to it
  3. Tailscale linking your machine to your OpenClaw cloud tenant
  4. OpenClaw routing AI tool calls through the tunnel to your browser

No fingerprinting issues. No re-authentication. Your existing sessions, cookies, and browser history — available to your AI agent, with your approval for each task.

Install OpenClaw Box: @OpenClawBoxBot on Telegram