Remote CDP Port Blocked — "Not by OpenClaw"
Regression in 2026.2.12
Tracked in openclaw/openclaw#15582. When using a remote CDP endpoint (Browserless, Puppeteer, or any external Chrome), OpenClaw rejects the connection with a false "port in use" error. The port ownership check does not account for remote profiles.
You configured a browser profile to point at a remote Browserless or Chrome DevTools endpoint. The endpoint is up (you can verify with curl), but OpenClaw refuses to connect with: "Port 3145 is in use for profile 'remote' but not by openclaw."
Next Step
Fix now, then reduce repeat incidents
If this issue keeps coming back, validate your setup in Doctor first, then harden your config.
Jump to Section
What the Error Looks Like
When you run a browser command targeting a remote profile:
openclaw browser open https://example.com --browser-profile remote --timeout 30000
The error specifically says "not by openclaw." Of course it's not — the port belongs to your Browserless container or remote Chrome instance. That's the whole point of a remote profile.
Why This Happens
Port ownership check is unconditional
The browser profile validator runs a port ownership check for all profiles that have an active port. It checks whether the PID listening on that port belongs to the OpenClaw process tree. For remote endpoints, the port is on another machine entirely — so this check always fails.
Check fires before connection attempt
The ownership validation runs before the WebSocket attachment logic. This means even setting browser.attachOnly=true has no effect — the error is thrown before OpenClaw ever tries to connect to the remote endpoint.
Regression from local safety feature
This check was added to prevent OpenClaw from accidentally connecting to browser instances owned by other programs. Legitimate safety concern for local profiles, but the code doesn't distinguish between local and remote CDP endpoints.
Confirm the Remote Endpoint Is Reachable
Before troubleshooting the OpenClaw side, verify the remote browser is actually responding:
# Replace with your actual endpoint
curl -s http://172.30.224.1:3145/json/version | head -5
# You should see something like:
# { "Browser": "Chrome/125.0.6422.60", "Protocol-Version": "1.3", ... }If curl returns valid JSON with Browser and Protocol-Version, your endpoint is fine. The problem is 100% on the OpenClaw validation side.
Fix A: Reset the Browser Profile
Clearing the cached profile state removes the stale port mapping that triggers the ownership check. This is a temporary workaround — the error may return on the next gateway restart.
openclaw browser action=reset-profile profile=remote # Then retry your command openclaw browser open https://example.com --browser-profile remote --timeout 30000
Fix B: Upgrade to a Patched Version
PR #15595 adds a !remoteCdp guard to the port ownership check, allowing remote profiles to bypass local validation entirely. Upgrade to any version after this merge.
npm install -g openclaw@latest openclaw gateway restart
Fix C: Use Direct WebSocket URL
If you can't upgrade yet, bypass the profile system entirely by passing the WebSocket URL directly:
# Get the WebSocket debugger URL from your remote endpoint WS_URL=$(curl -s http://172.30.224.1:3145/json/version | python3 -c "import json,sys; print(json.load(sys.stdin)['webSocketDebuggerUrl'])") # Use it directly (bypasses profile validation) openclaw browser open https://example.com --browser-ws "$WS_URL" --timeout 30000
The --browser-ws flag skips all profile logic including port checks, but also skips profile-level settings like viewport size and cookies. Use this as a stopgap, not a permanent solution.
Verify It Works
Expected: Page loads, screenshot taken, or tool action completes
Expected: "remote" profile shows status: connected, endpoint: ws://...
Expected: No output (empty = good)
Still Stuck?
If you're still getting the error after reset, check that your profile config is correctly typed as remote:
openclaw config get browser
# Look for your profile. It should show:
# "remote": { "type": "remote-cdp", "endpoint": "http://..." }
# NOT: "remote": { "type": "local", ... }Run the Doctor
Checks browser profile configuration, endpoint connectivity, and port conflicts.
Related Issues
Other browser & connection problems:
Fix It Faster With Our Tools
Did this guide solve your problem?