diff --git a/website/docs/user-guide/features/browser.md b/website/docs/user-guide/features/browser.md
index 7026169fbb..c41b3f7abe 100644
--- a/website/docs/user-guide/features/browser.md
+++ b/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.