Bug Description

The browser tool fails to connect to external CDP servers (like Steel Browser, self-hosted Browserless, etc.) with the error:

Port XXXX is in use for profile "profilename" but not by openclaw

This happens because OpenClaw appears to check whether it "owns" the process listening on the CDP port, which will always fail for remote/external browser services.

Steps to Reproduce

1. Set up an external CDP server (tested with Steel Browser on a separate machine)
2. Configure OpenClaw with a browser profile pointing to the external CDP endpoint:

"browser": {
  "enabled": true,
  "attachOnly": true,
  "defaultProfile": "steel",
  "profiles": {
    "steel": {
      "cdpUrl": "http://192.168.0.125:9223"
    }
  }
}

3. Try to use the browser tool: browser open or browser screenshot

Expected Behavior

OpenClaw should connect to the external CDP server and control the browser.

Actual Behavior

The tool fails immediately with:

Port 9223 is in use for profile "steel" but not by openclaw

The error occurs before any actual CDP connection attempt is made.

Environment

• OpenClaw version: latest (npm)
• OS: Ubuntu 22.04 (headless server)
• External browser: Steel Browser (Chrome/144.0.7559.96) on separate machine
• CDP endpoint verified working via curl: curl http://192.168.0.125:9223/json/version returns valid response

Additional Context

• The browser status and browser tabs commands work fine
• Direct CDP connections work (verified with Playwright connecting to the same endpoint)
• The Steel REST API works as a workaround (/v1/screenshot, /v1/scrape, etc.)
• This may affect any external CDP provider, not just Steel
• The attachOnly: true setting does not bypass this check

Suggested Fix

The port ownership check should be skipped when the cdpUrl points to a non-localhost address, or when attachOnly: true is set.