--- name: browser-use description: "Existing Chrome automation: Chrome plugin first; OpenClaw extension-backed mcporter fallback." --- # Browser Use Use this for browser tasks against the existing Chrome session. Config repair details live in `mcporter-config.md`. ## Route 1. If the Codex `Chrome` or `Chrome [Internal]` plugin is callable in the current session, use its bundled Chrome-control skill. 2. Otherwise use the mcporter `chrome-devtools` route below. Bundled or installed on disk does not mean available; the plugin must be callable in the active session. Both routes must use the user's existing Chrome profile. For the mcporter fallback, use this target: ```bash mcporter call chrome-devtools. ``` Most login-heavy sites fail in isolated profiles because fresh sessions trigger captcha, device checks, or missing SSO/extension state. Strongly prefer the existing Chrome profile for any website that needs login. Never use `chrome-isolated`, Playwright, Puppeteer, the Codex in-app browser, AppleScript, `osascript`, GUI scripting, or macOS `open` for browser control unless the user explicitly asks for an isolated/new browser. Screenshot/live UI bugs require this existing-Chrome path. `curl`, source inspection, Worker smoke tests, or local Playwright are supporting proof only; do not treat them as equivalent when the user showed a rendered browser problem or the page may depend on login/profile state. ## Prompt-free OpenClaw relay Current mcporter `main` can replace `chrome-devtools-mcp --autoConnect` with the paired OpenClaw extension relay. This keeps the real Chrome profile while avoiding Chrome's blocking **Allow remote debugging?** dialog. Use this route when the OpenClaw checkout and extension are available: The examples use an installed `openclaw` command. If it is absent, run the same arguments as `pnpm -s openclaw ...` from `~/Projects/openclaw`. 1. Resolve and verify the unpacked extension directory before presenting it: ```bash extension_dir="$(openclaw browser extension path)" if [ ! -f "$extension_dir/manifest.json" ]; then extension_dir="$HOME/Projects/openclaw/extensions/browser/chrome-extension" fi test -f "$extension_dir/manifest.json" printf '%s\n' "$extension_dir" ``` A source checkout may report an unstaged `dist/extensions/...` path. Never hand that path to the user unless `manifest.json` exists. The verified source fallback is `~/Projects/openclaw/extensions/browser/chrome-extension`. 2. In the real Chrome profile, open `chrome://extensions`, enable Developer mode, choose **Load unpacked**, and select the verified directory. Use Peekaboo for UI automation or give the user the exact verified path. 3. Start or reach the OpenClaw gateway/browser service, then generate and paste the pairing string with `openclaw browser extension pair`. Pairing strings contain a host-local secret: never print one in chat or tool output. For automated local pairing, extract `pairingString` from `--json` directly into `pbcopy`, paste only into the confirmed OpenClaw popup, and clear the clipboard immediately afterward. 4. Run `openclaw browser status --browser-profile chrome --json` to activate the browser sidecar when necessary. The extension popup must say **Connected to OpenClaw**. Share one controlled tab; success moves it into the orange **OpenClaw** tab group. 5. Confirm the mcporter definition is still the normal auto-connect form: ```bash mcporter config get chrome-devtools # Transport should include: chrome-devtools-mcp ... --autoConnect ``` Do not manually replace the server definition with a token-bearing command. mcporter reads `~/.openclaw/credentials/browser-extension-relay.secret`, probes the relay, and rewrites the child arguments in memory. 6. Use a mcporter build that contains the relay rewrite. When testing current source rather than the installed binary: ```bash cd "$HOME/Projects/mcporter" pnpm install pnpm build node dist/cli.js --version ``` Call that `node dist/cli.js` entry point for the proof; an older global `mcporter` binary does not prove current `main`. The default relay URL is `http://127.0.0.1:18799`. A custom gateway port can produce a different relay port; read `relayPort` from `openclaw browser extension pair --json` and pass only the non-secret URL: ```bash relay_port=18799 # replace with the reported relayPort when non-default MCPORTER_CHROME_DEVTOOLS_RELAY_URL="http://127.0.0.1:$relay_port" \ mcporter call chrome-devtools.list_pages --args '{}' --output text ``` If OpenClaw uses a custom `OPENCLAW_STATE_DIR`, pass the same variable to mcporter so it can find the relay secret. Never display the secret itself. ### Relay proof After sharing a controlled tab, prove read and write access through the normal `--autoConnect` definition: ```bash mcporter call chrome-devtools.list_pages --args '{}' --output text mcporter call chrome-devtools.navigate_page \ --args '{"url":"https://example.com/?mcporter-relay-proof=1"}' --output text mcporter call chrome-devtools.evaluate_script \ --args '{"function":"() => ({title: document.title, href: location.href})"}' \ --output text ``` Success requires all of the following: - `list_pages` shows the explicitly shared real-profile tab, not an isolated blank Chrome. - navigation and evaluation return the proof URL from that tab. - Chrome does not show the blocking **Allow remote debugging?** dialog. - Chrome may show the dismissible **"OpenClaw" started debugging this browser** banner with a **Cancel** button. That banner is expected; Cancel revokes the tab share and is not the MCP attach alert. If the blocking remote-debugging dialog appears while the extension is paired, treat the relay rewrite as failed. Check the mcporter binary, relay URL, shared tab, secret location, and relay reachability before clicking anything. Do not count a fallback `--autoConnect` attachment as success for this flow. ## Check MCP The attach-alert recovery below is only for the direct/legacy `--autoConnect` path when the extension relay is unavailable. During an OpenClaw relay proof, do not click **Allow remote debugging?**; its appearance means the rewrite did not apply. ```bash mcporter list chrome-devtools --schema mcporter call chrome-devtools.list_pages --args '{}' --output text ``` `list_pages` must show the user's real open tabs. If it shows a blank/default isolated Chrome, stop and say reattach failed. If the call appears to hang while Chrome shows an auth/attach/update prompt, handle the attach alert before falling back. Prefer Peekaboo to press an explicit Chrome `Allow` button when visible; otherwise wait for the human. Do not restart daemons or kill MCP processes just because the first output is slow. Tested attach-prompt recovery: ```bash PB="${PEEKABOO_BIN:-$HOME/bin/peekaboo}" [ -x "$PB" ] || PB="$(command -v peekaboo)" "$PB" permissions status --json "$PB" see --app frontmost --path /tmp/chrome-attach.png --json --annotate # If the UI shows Chrome "Allow remote debugging?", click only the visible Allow button. "$PB" click --coords , --json mcporter call chrome-devtools.list_pages --args '{}' --output text ``` Use coordinates from the current Peekaboo snapshot, not stale notes. Success means `list_pages` returns the user's real Chrome tabs. Attach-alert rule: when the current snapshot clearly shows Chrome asking to allow DevTools/MCP/browser automation attachment, click the visible `Allow` button once, then rerun `list_pages`. If the button is not visible or the prompt is ambiguous, stop and ask; do not silently switch to Playwright/Puppeteer. If `list_pages` fails with `DevToolsActivePort`, ask the user to restart Chrome or the DevTools bridge, then retry once: ```bash mcporter daemon restart mcporter call chrome-devtools.list_pages --args '{}' --output text ``` If it still fails, stop and say Chrome DevTools MCP is unavailable. Do not use AppleScript. Avoid noisy recovery loops. Repeated MCP/browser restarts can trigger reconnect/login prompts and alerts. Try once, then pause and choose a quieter path. ## Typical Flow ```bash # pick the page id from list_pages mcporter call chrome-devtools.select_page --args '{"pageId":9}' --output text # inspect page mcporter call chrome-devtools.take_snapshot --args '{}' --output text # navigate selected page mcporter call chrome-devtools.navigate_page --args '{"url":"https://example.com"}' --output text # click an element uid from the latest snapshot mcporter call chrome-devtools.click --args '{"uid":"1_38","includeSnapshot":true}' --output text # type/fill mcporter call chrome-devtools.fill --args '{"uid":"1_13","value":"text","includeSnapshot":true}' --output text # run JS, keep secrets out of output mcporter call chrome-devtools.evaluate_script --args '{"function":"() => document.title"}' --output json ``` Use `take_snapshot` before actions and use current `uid` values only. Avoid `take_screenshot` unless visual layout matters. ## Live UI Proof For screenshot regressions, deployed dashboard checks, or anything where the rendered browser is the bug: ```bash mcporter call chrome-devtools.list_pages --args '{}' --output text mcporter call chrome-devtools.select_page --args '{"pageId":9}' --output text mcporter call chrome-devtools.navigate_page --args '{"url":"https://example.com"}' --output text mcporter call chrome-devtools.take_snapshot --args '{}' --output text mcporter call chrome-devtools.evaluate_script --args '{"function":"() => document.body.innerText"}' --output json ``` Use the existing logged-in/profile-bearing tab set. If browser automation is unavailable, report that as a verification gap instead of substituting isolated browser tooling. ## Secret Handling Never print tokens/passwords from page DOM, network logs, or inputs. For token checks, return shape only: present/absent, length, status code, account/org name.