docs(browser): the Chrome 136+ remote-debugging block is a consent dialog, not a silent failure

The `/browser connect` tip said Chrome 136+ "silently refuse[s] to open the
remote debugging port" on the default user-data-dir and that "there is no error
message". Chrome does surface it: on Chrome 152/macOS, launching the default
profile with --remote-debugging-port puts up an "Allow remote debugging?" dialog,
and the port opens once you press Allow. Port 9222 refusing connections is the
symptom while that consent is pending, not a permanent silent block.

Two details this cost time to rediscover, now written down:

- the consent is asked per launch, so it reappears on every browser restart
- the remote-debugging toggle in chrome://settings does not suppress it; that
  toggle only makes the feature available

Also cross-references browser.use_real_profile for the case the tip leaves
unanswered — wanting existing logins in the agent's browser. A dedicated
user-data-dir avoids the dialog but starts signed out; the real-profile snapshot
gets both, since the snapshot copy is itself a non-default user-data-dir.

Verified locally: default profile + --remote-debugging-port=9222 shows the
dialog and leaves 9222 closed, while a --user-data-dir launch answers
/json/version in under a second with no prompt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

website/docs/user-guide/features/browser.md

@@ -523,7 +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 silently refuse to open the remote debugging port when `--remote-debugging-port` is combined with the *default* user-data-dir — even from a cold start with no other Chrome running. The browser launches normally but nothing ever listens on 9222, so `/browser connect` (and any manual `curl http://127.0.0.1:9222/json/version`) fails with connection refused. There is no error message. 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`). This applies to Chrome, Chromium, Edge, and Brave builds that have picked up the change.
+**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.
+
+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.
 :::
 
 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.