fix(browser): skip port ownership check for remote CDP profiles#28780
Merged
vincentkoc merged 7 commits intoopenclaw:mainfrom Mar 2, 2026
Merged
fix(browser): skip port ownership check for remote CDP profiles#28780vincentkoc merged 7 commits intoopenclaw:mainfrom
vincentkoc merged 7 commits intoopenclaw:mainfrom
Conversation
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
Contributor
Greptile SummaryThis 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 The change is minimal and targeted:
The fix resolves reported issues from 7+ users across Kubernetes, Azure AKS, Railway, and Docker deployments. Confidence Score: 5/5
Last reviewed commit: 80e4463 |
1 task
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)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When a browser profile has a non-loopback
cdpUrl(e.g. Browserless, Kubernetes sidecar, or any external CDP service), the port-ownership check inensureBrowserAvailable()incorrectly fires because we don't "own" the remote process. This causes:...even though the remote CDP service is working and reachable.
Root cause
In
src/browser/server-context.ts, theensureBrowserAvailable()flow is:isReachable()) -- may fail due to timing or protocol differences!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
remoteCdpvariable (!profile.cdpIsLoopback) is already computed but not checked here.Fix
Add
&& !remoteCdpto the port ownership guard so remote profiles skip this check and fall through to the existing WebSocket retry/attach logic (which already handlesremoteCdpcorrectly).This is a minimal, targeted fix -- 1 line of logic changed.
Who is affected
Reported by 7+ users across Kubernetes, Azure AKS, Railway, and Docker deployments:
attachOnlyvariant)Testing
attachOnly || remoteCdpblock (line 345) which already handles reconnection with proper timeoutsFixes #15582