OpenClaw
OpenClaw finds its node-routed browser relay never starts
An OpenClaw report says node-routed browser control fails because the expected relay on gateway.port+2 never binds. A proposed fix starts the browser-control server when proxying is enabled, while related gateway work keeps the core available during sidecar startup.
openclaw/openclaw issue #124296 is the inspected primary source: “Node-routed browser tool always fails: local browser-control relay on gateway.port+2 never binds regardless of nodeHost.browserProxy.enabled.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- openclaw/openclaw issue #124296 was created 2026-08-15T22:02:01Z and was open at inspection; its title is “Node-routed browser tool always fails: local browser-control relay on gateway.port+2 never binds regardless of nodeHost.browserProxy.enabled.” - openclaw/openclaw PR #124327 was created 2026-08-16T01:06:24Z and was open at inspection; its title is “fix(node-host): start browser control HTTP server when browser proxy is enabled.” - openclaw/openclaw PR #124309 was created 2026-08-15T23:51:25Z and was open at inspection; its title is “fix(gateway): keep core available while sidecars start.” - The repository reported 386404 stars, 5537 open issues, default branch main, and last push 2026-08-16T01:06:13Z. - The latest tagged-release baseline checked was v2026.8.1-beta.2 published 2026-08-15T05:36:23Z.
What changed
openclaw/openclaw issue #124296 reports: Summary Calling the browser tool/action with target: "node" against *any* paired node (including a locally-connected CLI node-host on the same machine as the Gateway) always fails with the same error, because nothing on the Gateway host ever binds a listener on the derived browser-control port (gateway.port + 2). This makes remote/node-routed browser control completely non-functional, independent of node OS, SSH tunnel state, or the nodeHost.browserProxy.enabled config flag. Environment macOS Gateway, gateway.port: 18789 (default) nodeHost.browserProxy.enabled: true set explicitly (gateway + node-host service both restarted after this change) A local CLI node-host (openclaw node run) also running, connected to the same gateway, declaring the browser capability A separate remote Windows node, also declaring browser, connected via Windows Hub's SSH-tunnel gateway connection (SSH tunnel healthy, Hub shows "Gateway reachable") Steps to reproduce 1. Start gateway on default port 18789. 2. Set nodeHost.browserProxy.enabled: true, restart gateway + node-host. 3. Call browser tool with target: "node" and any connected node id (tested against 3 different node ids: local CLI node-host, and two distinct Windows node registrations) — all fail identically. Expected Node-routed browser calls should reach the target node's browser (or, for locally-connected node-hosts, should not require an additional local loopback listener at all, since the node-host process is already directly connected to the same
openclaw/openclaw PR #124327 reports: What Problem This Solves Calling the browser tool/action with target: "node" against any paired node always fails with the same error, because nothing on the Gateway host ever binds a listener on the derived browser-control port (gateway.port + 2). This makes remote/node-routed browser control completely non-functional. Root Cause The node host browser proxy (nodeHost.browserProxy.enabled) exposes the local browser control through node routing, but the HTTP server was never started on the node host. The ensureBrowserControlService function starts the service but doesn't bind the HTTP port. Fix Start the browser control HTTP server during node host runtime preparation when nodeHost.browserProxy.enabled is not false. Evidence **Issue:** #124296 **Test:** runtime.test.ts passes (15 tests) **Runtime:** The fix starts the browser control HTTP server on the node host, allowing the gateway to reach it on gateway.port + 2 Fixes #124296
openclaw/openclaw PR #124309 reports: Closes #78954 What Problem This Solves Fixes an issue where Gateway restarts could keep the TUI and operator control plane disconnected while channel, plugin-service, or worker sidecars were still starting. A slow or failed sidecar could therefore turn an otherwise usable core Gateway into an apparent startup wedge and amplify upgrade failures into supervisor restart instability. Why This Change Was Made The Gateway now uses its existing deferred-sidecar lifecycle by default. Mandatory post-bind preparation still completes before operator admission, startup-dependent methods remain retryably gated, and full startup probes, node/worker clients, and update verification continue waiting for sidecar completion. This keeps one canonical startup sequence, removes the CLI-only skip-mode selector, and adds no config, protocol version, or schema surface. User Impact Authenticated operator clients, including the TUI, can connect to core Gateway state while sidecars continue starting. /startupz, probe clients, nodes, workers, and methods that require startup state remain unavailable until full startup completes. Sidecar failure stays recorded instead of tearing down the core transport. Evidence Regression test updated from whole-connection startup rejection to operator admission while full startup remains pending. Probe startup rejection remains covered in the same test file. Focused Gateway suite: 73/73 passed on direct AWS Crabbox cbx_3f60e7160d92, run run_274ee151d652. Changed gate: formatting and 15 static guards passed.
Why it matters
Remote browser routing is not a feature if the local relay is absent. Startup sequencing also decides whether a delayed sidecar becomes a narrow impairment or a whole-gateway outage. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-16. The tagged-release baseline was v2026.8.1-beta.2 published 2026-08-15T05:36:23Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/openclaw/openclaw/issues/124296. Supporting records are https://github.com/openclaw/openclaw/pull/124327 and https://github.com/openclaw/openclaw/pull/124309. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Test the relay port and browser round trip during node-host startup, separate core readiness from sidecar readiness, and expose both states in health receipts. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.