Browser Use

Control the user's existing real Chrome profile, especially for login-dependent work and live UI verification.

Route

1. Use the Codex Chrome or Chrome [Internal] plugin when it is callable in the active session. Installed on disk is not enough.
2. Otherwise prefer the OpenClaw extension-backed mcporter route.
3. Use legacy direct DevTools attachment only as the explicit last fallback.

For mcporter, the MCP call remains the agent-facing control interface. The OpenClaw extension is the transport underneath it, not a separate tool. Set chromeDevtoolsRelay: "require" on the canonical global Chrome server definition to enforce relay-only routing. Keep the caller policy explicit as well:

MCPORTER_CHROME_DEVTOOLS_RELAY_POLICY=require mcporter call chrome-devtools.<tool>

Seeing an agent request the chrome-devtools MCP tool is therefore expected. A Chrome Allow remote debugging? prompt or a relay-policy error indicates that the extension transport was not used. The shared daemon retains canonical policy; a shell environment prefix alone cannot change that policy.

Never use isolated Chrome, the Codex in-app browser, Playwright, Puppeteer, AppleScript, osascript, generic GUI scripting, or macOS open as a browser-control substitute unless the user explicitly asks for an isolated or new browser. Peekaboo is allowed only for Chrome or extension setup and visible prompts. Login-heavy sites often depend on the real profile's cookies, SSO, device trust, and extensions.

For a rendered-browser bug, prove behavior through this real profile. Treat curl, source inspection, API checks, and isolated test browsers as supporting evidence, not substitutes for live UI proof.

Extension Relay Model