Skip to content

fix(browser): skip port ownership check for remote CDP profiles#28780

Merged
vincentkoc merged 7 commits intoopenclaw:mainfrom
stubbi:fix/remote-cdp-port-check
Mar 2, 2026
Merged

fix(browser): skip port ownership check for remote CDP profiles#28780
vincentkoc merged 7 commits intoopenclaw:mainfrom
stubbi:fix/remote-cdp-port-check

Conversation

@stubbi
Copy link
Contributor

@stubbi stubbi commented Feb 27, 2026

Summary

When a browser profile has a non-loopback cdpUrl (e.g. Browserless, Kubernetes sidecar, or any external CDP service), the port-ownership check in ensureBrowserAvailable() incorrectly fires because we don't "own" the remote process. This causes:

Port 9222 is in use for profile "default" but not by openclaw.
Run action=reset-profile profile=default to kill the process.

...even though the remote CDP service is working and reachable.

Root cause

In src/browser/server-context.ts, the ensureBrowserAvailable() flow is:

  1. Check if port is HTTP-reachable -- yes (sidecar is running)
  2. Check if full CDP WebSocket handshake succeeds (isReachable()) -- may fail due to timing or protocol differences
  3. If WebSocket fails and !profileState.running -- throw "Port in use but not by openclaw"

Step 3 doesn't account for remote CDP profiles where we never own the process. The remoteCdp variable (!profile.cdpIsLoopback) is already computed but not checked here.

Fix

Add && !remoteCdp to the port ownership guard so remote profiles skip this check and fall through to the existing WebSocket retry/attach logic (which already handles remoteCdp correctly).

-    if (!profileState.running) {
+    if (!profileState.running && !remoteCdp) {

This is a minimal, targeted fix -- 1 line of logic changed.

Who is affected

  • Kubernetes sidecar setups (shared network namespace -- sidecar port is locally visible)
  • Docker Compose setups with separate Browserless/Chromium containers
  • Any remote CDP configuration where the port happens to be reachable from the host

Reported by 7+ users across Kubernetes, Azure AKS, Railway, and Docker deployments:

Testing

  • Verified that the fix matches the community-proposed solution by @bsormagec
  • Code review: remote profiles fall through to the attachOnly || remoteCdp block (line 345) which already handles reconnection with proper timeouts
  • Integration test with Kubernetes sidecar (Browserless + OpenClaw in same pod)

Fixes #15582

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582
@greptile-apps
Copy link
Contributor

greptile-apps bot commented Feb 27, 2026

Greptile Summary

This PR fixes a bug where remote CDP profiles (Browserless, Kubernetes sidecars, external CDP services) incorrectly trigger a "port in use but not by openclaw" error. The fix adds && !remoteCdp to a conditional check in ensureBrowserAvailable() at src/browser/server-context.ts:338, allowing remote CDP profiles to skip the port ownership validation and proceed to the existing reconnection logic that already handles remote profiles correctly.

The change is minimal and targeted:

  • Root cause: The port ownership check didn't account for remote CDP profiles where OpenClaw never owns the process
  • Solution: Skip the ownership check when remoteCdp is true (computed as !profile.cdpIsLoopback)
  • Impact: Remote CDP profiles now properly fall through to lines 346-357 where they're handled with appropriate retry logic and error messages
  • Consistency: The remoteCdp variable is already checked elsewhere in the same function (lines 313, 319, 346), making this fix consistent with existing patterns

The fix resolves reported issues from 7+ users across Kubernetes, Azure AKS, Railway, and Docker deployments.

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk
  • The fix is a minimal, well-targeted one-line change that correctly addresses a logic bug. The remoteCdp variable is already used in multiple places in the same function, making this change consistent with existing patterns. The fix allows remote CDP profiles to skip an inappropriate check and reach the correct error handling code that was already designed for this scenario. No breaking changes or side effects are introduced.
  • No files require special attention

Last reviewed commit: 80e4463

@vincentkoc vincentkoc merged commit 5bb26bf into openclaw:main Mar 2, 2026
6 checks passed
steipete pushed a commit to Sid-Qin/openclaw that referenced this pull request Mar 2, 2026
…claw#28780)

* fix(browser): skip port ownership check for remote CDP profiles

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582

* fix: add TypeScript null guard for profileState.running

* chore(changelog): note remote CDP ownership fix credits

Refs openclaw#15582

* Update CHANGELOG.md

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
robertchang-ga pushed a commit to robertchang-ga/openclaw that referenced this pull request Mar 2, 2026
…claw#28780)

* fix(browser): skip port ownership check for remote CDP profiles

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582

* fix: add TypeScript null guard for profileState.running

* chore(changelog): note remote CDP ownership fix credits

Refs openclaw#15582

* Update CHANGELOG.md

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
hanqizheng pushed a commit to hanqizheng/openclaw that referenced this pull request Mar 2, 2026
…claw#28780)

* fix(browser): skip port ownership check for remote CDP profiles

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582

* fix: add TypeScript null guard for profileState.running

* chore(changelog): note remote CDP ownership fix credits

Refs openclaw#15582

* Update CHANGELOG.md

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
execute008 pushed a commit to execute008/openclaw that referenced this pull request Mar 2, 2026
…claw#28780)

* fix(browser): skip port ownership check for remote CDP profiles

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582

* fix: add TypeScript null guard for profileState.running

* chore(changelog): note remote CDP ownership fix credits

Refs openclaw#15582

* Update CHANGELOG.md

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
dawi369 pushed a commit to dawi369/davis that referenced this pull request Mar 3, 2026
…claw#28780)

* fix(browser): skip port ownership check for remote CDP profiles

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582

* fix: add TypeScript null guard for profileState.running

* chore(changelog): note remote CDP ownership fix credits

Refs openclaw#15582

* Update CHANGELOG.md

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
sachinkundu pushed a commit to sachinkundu/openclaw that referenced this pull request Mar 6, 2026
…claw#28780)

* fix(browser): skip port ownership check for remote CDP profiles

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582

* fix: add TypeScript null guard for profileState.running

* chore(changelog): note remote CDP ownership fix credits

Refs openclaw#15582

* Update CHANGELOG.md

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
zooqueen pushed a commit to hanzoai/bot that referenced this pull request Mar 6, 2026
…claw#28780)

* fix(browser): skip port ownership check for remote CDP profiles

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582

* fix: add TypeScript null guard for profileState.running

* chore(changelog): note remote CDP ownership fix credits

Refs openclaw#15582

* Update CHANGELOG.md

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
atlastacticalbot pushed a commit to tensakulabs/atlasbot that referenced this pull request Mar 6, 2026
…claw#28780)

* fix(browser): skip port ownership check for remote CDP profiles

When a browser profile has a non-loopback cdpUrl (e.g. Browserless,
Kubernetes sidecar, or any external CDP service), the port-ownership
check incorrectly fires because we don't "own" the remote process.
This causes "Port is in use but not by openclaw" even though the
remote CDP service is working and reachable.

Guard the ownership error with !remoteCdp so remote profiles fall
through to the WebSocket retry/attach logic instead.

Fixes openclaw#15582

* fix: add TypeScript null guard for profileState.running

* chore(changelog): note remote CDP ownership fix credits

Refs openclaw#15582

* Update CHANGELOG.md

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
(cherry picked from commit 5bb26bf)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Remote CDP (Browserless) blocked with “Port is in use … but not by openclaw” (OpenClaw 2026.2.12)

2 participants