chrome-mcp — dedicated Chrome launcher for chrome-devtools MCP (CDP attach) that keeps daily-browsing profile clean from navigator.webdriver=true and the reCAPTCHA hits that come with it

A developer created chrome-mcp, a dedicated Chrome launcher for the chrome-devtools MCP server that isolates automation profiles from daily browsing. The tool prevents reCAPTCHA triggers and security risks by running a separate Chrome instance with its own user data directory and binding the debugging port only to localhost. It includes a pre-flight check to avoid port conflicts and helps restore trust scores on the daily browser.

A dedicated Chrome launcher for the chrome-devtools MCP https://github.com/ChromeDevTools/chrome-devtools-mcp server and any other tool that attaches to Chrome via the Chrome DevTools Protocol . Keeps the daily-browsing profile clean. To let an AI / MCP / automation tool drive Chrome, you typically launch Chrome with --remote-debugging-port=9222 . That works, but it has two ugly side-effects on whichever Chrome you point it at : This is reCAPTCHA's single strongest "this is an automated browser" signal. Even casual browsing starts triggering "verify you're human" challenges, image-grid puzzles, and silently-elevated risk scores at Cloudflare / Akamai / Google. navigator.webdriver === true on every page you visit. Whatever bind address you used is exposed. Many tutorials suggest --remote-debugging-address=0.0.0.0 , which means anyone on your LAN or the wider network if the host is reachable can attach a debugger to your Chrome — read tabs, inject scripts, exfiltrate cookies. Not great. If you set those flags on your daily Chrome e.g. by editing the .desktop launcher , every page you load from then on is fingerprinted as automation . The reCAPTCHA hits become constant. Site trust scores tank. Runs a separate Chrome instance with: - Its own --user-data-dir ~/.chrome-mcp-profile — completely isolated cookies, history, extensions, and login state from your daily profile. --remote-debugging-port=9222 bound to 127.0.0.1 only — not 0.0.0.0 . Only local processes your MCP can attach; nothing on the LAN can.- A pre-flight check that refuses to start if anything is already listening on :9222 catches the common mistake where the daily browser is still running with the flag inherited from a leftover .desktop override . Your daily Chrome stays plain. navigator.webdriver is undefined there. reCAPTCHA trust score recovers within hours of removing the leak. chrome-mcp foreground; Ctrl+C to stop chrome-mcp --headless no UI still attachable on 9222 chrome-mcp --bg background; logs to /tmp/chrome-mcp.log mkdir -p ~/bin curl -fsSL https://gist.githubusercontent.com/ProxiBlue/31fb2a1e5cd253ce903782235274eedb/raw/chrome-mcp -o ~/bin/chrome-mcp chmod +x ~/bin/chrome-mcp ensure ~/bin is on PATH Ubuntu adds it via .profile if the dir exists at login If you previously had --remote-debugging-port=9222 in a .desktop launcher, strip it out: sed -i 's/ --remote-debugging-port=9222 --remote-debugging-address=0\.0\.0\.0//g' \ ~/.local/share/applications/google-chrome.desktop fully quit Chrome close all windows + crashpad , then relaunch pkill -f 'google-chrome. remote-debugging-port' ; sleep 2 After launching: curl -s http://127.0.0.1:9222/json/version | python3 -m json.tool The userDataDir field should mention ".chrome-mcp-profile" — NOT Default. On your daily browser, open the JS console and check: navigator.webdriver // expected: undefined NOT true Visit https://bot.sannysoft.com https://bot.sannysoft.com to see a fuller fingerprint check. Playwright's --isolated mode creates a fresh browser CONTEXT per session inside the same browser. That works for Playwright's own scripted runs, but the chrome-devtools MCP attaches to an already-running Chrome via CDP — there's no Playwright runtime to isolate. The chrome-mcp script is the equivalent for the CDP-attach case: a separate process with its own profile dir. MIT.