From 853bfec43afad7dc6faaf44f63e046bfbed15466 Mon Sep 17 00:00:00 2001 From: teknium1 <127238744+teknium1@users.noreply.github.com> Date: Sat, 12 Sep 2026 08:15:00 -0700 Subject: [PATCH] docs(browser): separate Chrome 136 flag refusal from the 144+ approval dialog MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The salvaged paragraph described one mechanism that is actually two. Per developer.chrome.com/blog/remote-debugging-port, Chrome 136+ simply stops respecting --remote-debugging-port/--remote-debugging-pipe against the default data dir — no dialog, nothing listens. The "Allow remote debugging?" prompt the contributor saw is the separate Chrome 144+ opt-in approval flow (chrome://inspect/#remote-debugging), which asks per incoming connection, not per launch. Say so, cite both sources, and keep the fix (non-default --user-data-dir, or use_real_profile) unchanged. --- website/docs/user-guide/features/browser.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/docs/user-guide/features/browser.md b/website/docs/user-guide/features/browser.md index c41b3f7abe..0285b9a81b 100644 --- a/website/docs/user-guide/features/browser.md +++ b/website/docs/user-guide/features/browser.md @@ -523,9 +523,9 @@ Then launch the Hermes CLI and run `/browser connect`. **Why `--user-data-dir`?** Without it, launching a Chromium-family browser while a regular instance is already running typically opens a new window on the existing process — and that existing process was not started with `--remote-debugging-port`, so port 9222 never opens. A dedicated user-data-dir forces a fresh browser process where the debug port actually listens. `--no-first-run --no-default-browser-check` skips the first-launch wizard for the fresh profile. -**Chrome 136+ makes the dedicated profile mandatory.** As a security hardening change, Chrome 136 and later refuse to open the remote debugging port when `--remote-debugging-port` is combined with the *default* user-data-dir unless you explicitly consent — even from a cold start with no other Chrome running. On current builds (verified on Chrome 152, macOS) the browser starts normally and puts up an **"Allow remote debugging?"** dialog explaining that an external app wants full control of the session. Nothing listens on 9222 until you press **Allow**, so `/browser connect` (and any manual `curl http://127.0.0.1:9222/json/version`) fails with connection refused up to that point. The consent is asked per launch, so the dialog comes back every time the browser restarts. Turning on the remote-debugging toggle in `chrome://settings` does not remove it — that only makes the feature available; the per-launch dialog still appears. The fix is exactly the commands above: always pass a `--user-data-dir` pointing somewhere other than your default profile directory (e.g. `$HOME/.hermes/chrome-debug`), which skips the consent dialog entirely. This applies to Chrome, Chromium, Edge, and Brave builds that have picked up the change. +**Chrome 136+ makes the dedicated profile mandatory.** Two separate mechanisms are in play, and neither applies once you pass a non-default `--user-data-dir`. First, since [Chrome 136](https://developer.chrome.com/blog/remote-debugging-port) `--remote-debugging-port` and `--remote-debugging-pipe` "will no longer be respected if attempting to debug the default Chrome data directory" — the flag is silently ignored, no dialog, and `/browser connect` (or `curl http://127.0.0.1:9222/json/version`) gets connection refused even from a cold start. Second, [Chrome 144+](https://developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session) adds an opt-in *approval* flow for debugging your real profile: you enable it under `chrome://inspect/#remote-debugging`, and Chrome then shows an **"Allow remote debugging?"** dialog for **every incoming connection** (not once per launch), with nothing listening until you press **Allow**. If you see that dialog, you are on the approval path, not the flag path. The fix is exactly the commands above: point `--user-data-dir` somewhere other than your default profile directory (e.g. `$HOME/.hermes/chrome-debug`), which needs neither the toggle nor the dialog. This applies to Chrome, Chromium, Edge, and Brave builds that have picked up the change. -A dedicated profile starts out signed out of everything. If you want the agent to browse with your existing logins *and* no consent dialog, use [`browser.use_real_profile`](#real-profile-browsing-use-your-own-logins) instead: it snapshots your active profile into a copy and drives that, which is a non-default user-data-dir and so never triggers the prompt. +A dedicated profile starts out signed out of everything. If you want the agent to browse with your existing logins *and* no approval dialog, use [`browser.use_real_profile`](#real-profile-browsing-use-your-own-logins) instead: it snapshots your active profile into a copy and drives that, which is a non-default user-data-dir and so never triggers either mechanism. ::: When connected via CDP, all browser tools (`browser_navigate`, `browser_click`, etc.) operate on your live browser instance instead of spinning up a cloud session.