#13568: Fix browser (OpenClaw-managed) launch fail by binding remote debugging address

Fix: Add --remote-debugging-address=127.0.0.1 to Chrome launch args to prevent gateway timeout on loopback Problem When attempting to start a managed browser profile (e.g., openclaw browser --browser-profile openclaw start), the command fails with a "gateway timeout after 15000ms" error if the configuration uses loopback (default: ws://127.0.0.1:18789). This occurs because Chrome's remote debugging defaults to binding on all interfaces unless explicitly set, leading to connection issues in local environments. Reproduction steps: OS: Ubuntu-based VM 1) Ensure a profile like "openclaw" is configured with cdpPort: 18800 and bound to loopback. "browser": { "enabled": true, "remoteCdpTimeoutMs": 1500, "remoteCdpHandshakeTimeoutMs": 3000, "color": "#FF4500", "executablePath": "/usr/bin/google-chrome-stable", "headless": false, "noSandbox": false, "attachOnly": false, "defaultProfile": "openclaw", "profiles": { "openclaw": { "cdpPort": 18800, "color": "#FF4500" }, "work": { "cdpPort": 18801, "color": "#0066CC" }, "chrome": { "cdpUrl": "http://127.0.0.1:18792", "driver": "extension", "color": "#00AA00" } } openclaw browser --browser-profile openclaw status openClaw 2026.2.9 (33c75cb) — Siri's competent cousin. profile: openclaw enabled: true running: false cdpPort: 18800 cdpUrl: http://127.0.0.1:18800 browser: unknown detectedBrowser: custom detectedPath: /usr/bin/google-chrome-stable profileColor: #FF4500 2) Run openclaw browser --browser-profile openclaw start 3) Observe the timeout error: Error: gateway timeout after 15000ms Gateway target: ws://127.0.0.1:18789 Source: local loopback Config: /home/openclaw/.openclaw/openclaw.json Bind: loopback Solution: Add "--remote-debugging-address=127.0.0.1" immediately before "--remote-debugging-port=${profile.cdpPort}" in the launch arguments array in src/browser/chrome.ts. This explicitly binds remote debugging to localhost, resolving the timeout and allowing successful connections over loopback. As a temporary workaround, I manually edited the built files in ~/.npm-global/lib/node_modules/openclaw/dist/ (e.g., chrome-BxmeoNyo.js, etc.), but this PR applies the change to the source for proper builds. openclaw-Virtual-Machine:~/.openclaw$ openclaw browser --browser-profile openclaw start 🦞 OpenClaw 2026.2.9 (33c75cb) — Your messages, your servers, your control. │ ◇ │ ◇ 🦞 browser [openclaw] running: true Changes: Updated src/browser/chrome.ts to include the address flag in the args. Testing: - Built locally with pnpm build. - Ran openclaw browser --browser-profile openclaw start – browser launches successfully (running: true). - Verified status with openclaw browser --browser-profile openclaw status. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates the managed Chrome launch arguments in `src/browser/chrome.ts` to explicitly bind the DevTools/remote debugging interface to loopback by adding `--remote-debugging-address=127.0.0.1` before `--remote-debugging-port=...`. This fits the existing contract in `launchOpenClawChrome` which only launches local browser when `profile.cdpIsLoopback` is true, and it aligns with the rest of the file’s CDP logic (e.g., `cdpUrlForPort` hardcoding `127.0.0.1`). The change should prevent local connection timeouts when the gateway/client expects CDP to be reachable on localhost. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - The change is a single additional Chrome flag in the local-only launch path, consistent with existing loopback-only assumptions (`profile.cdpIsLoopback`, `cdpUrlForPort`), and does not alter control flow or data structures. - No files require special attention <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->