How OpenClaw Hardened Browser Control in Early 2026

OpenClaw browser automation did not become a privileged surface in one dramatic feature launch. It became one by accumulation: tab control moved behind the Gateway, sandboxed browsers gained a host bridge, a Chrome extension relayed DevTools traffic, and observer and navigation paths expanded around them.

From late January through February 2026, the project made that privilege explicit in shipped releases and security fixes. Across versions 2026.1.29 through 2026.2.22, OpenClaw centralised browser control and then hardened four different boundaries: who could call the bridge, who could join the extension relay, where a browser could navigate, and which credential a local CDP probe was allowed to carry.

The operator consequence is still useful: loopback is a routing choice, not authentication; a browser sandbox is not the same thing as a browser-control sandbox; and access to CDP is access to the session behind it.

The architectural change came first

OpenClaw 2026.1.29 removed the standalone browser-control command and its separate control-URL configuration. Browser requests instead ran through the Gateway or a node proxy, with browser ports derived from the Gateway port.

That was an operational simplification, but also a trust-boundary change. Browser control was no longer a sidecar operators could reason about independently. It became part of the Gateway’s control plane and remote-node routing model.

The same release family introduced the sandbox browser bridge. The later project advisory identifies 2026.1.29-beta.1, published to npm on 30 January, as the first package that shipped it. The bridge made browser containers useful to agents by exposing control routes such as /profiles, /tabs, /tabs/open and /agent/* back to the host. In other words, containerising Chrome still required a privileged path through the container wall.

The sandbox had a control path without authentication

That bridge path was the first boundary corrected. GHSA-h9g4-589h-68xv records that versions from 2026.1.29-beta.1 up to, but not including, 2026.2.14 could start the loopback bridge without Gateway authentication.

According to the advisory, a local process could enumerate tabs and CDP WebSocket URLs, navigate or close tabs, run JavaScript in page contexts, and obtain page or session data. The advisory classifies this as localhost-only; it does not claim a remote network exploit path.

Version 2026.2.14, published on 15 February, shipped the advisory’s authentication and loopback restrictions for the sandbox browser bridge. The advisory and release record support the boundary change; linked upstream patch records report dedicated bridge-auth coverage. OpenClaw Academy did not rerun the historical package.

The lesson was sharper than “turn on Docker.” A browser container can constrain the browser process while its host-side CDP bridge remains a separate authority boundary. Operators needed both isolation and authenticated control.

The extension relay needed the same rule

Five days later, OpenClaw 2026.2.19 applied the rule to the optional Chrome extension relay. Before the fix, GHSA-pfv7-rr5m-qmv6 says /extension accepted unauthenticated WebSocket upgrades even though /json/* and /cdp required authentication.

The advisory limits the exposure to loopback and machines using the extension relay. It says a same-machine process could connect and interfere with relay behaviour; it does not claim compromise from the public internet. Version 2026.2.19, published on 19 February, required the Gateway token on both /extension and /cdp and aligned extension setup around gateway.auth.token or OPENCLAW_GATEWAY_TOKEN.

This affected operators attaching OpenClaw to an existing Chrome session more than those using only a managed profile. Their practical task was to update both package and extension configuration, then treat an authentication failure as a boundary doing its job—not remove auth because the socket was “only local.”

Navigation and observation became explicit policy

Authentication answered who could control the browser. It did not answer where that browser could go or who could watch it.

The 2026.2.19 release record also described a merged navigation change that put tab-open, CDP-target and Playwright navigation through one SSRF guard, blocking private and metadata destinations by default with a browser.ssrfPolicy override. Crucially, those notes said the change would ship in the next npm release, so it should not be represented as delivered by 2026.2.19 itself.

Version 2026.2.21, published on 21 February, then documented a wider browser boundary:

• non-network protocols, including file:, were blocked for browser navigation, with about:blank retained;
• noVNC observer sessions required per-container password authentication and used short-lived observer URLs;
• sandbox browser containers defaulted to a dedicated openclaw-sandbox-browser Docker network;
• operators could restrict CDP ingress by source range, and openclaw security --audit warned about weaker bridge-network configurations.

These controls protected different things. SSRF and protocol checks constrained destinations. VNC authentication constrained observers. Docker networking constrained reachability. None substituted for CDP authentication.

A shared Gateway token was still too much credential

The next correction showed why authenticated is not the same as safely authenticated. GHSA-v3j7-34xh-6g3w says versions through 2026.2.21-2 added x-openclaw-relay-token to loopback CDP probes and sent it to /json/version. A malicious local listener on the probed port could capture the value and reuse it as Gateway bearer authentication.

The advisory is careful about scope: this mattered most on non-standard shared-user or shared-host deployments where an untrusted local process could bind or race the relay port. It did not change the documented single-owner threat model.

Version 2026.2.22, published on 23 February, shipped the fix. The patch derives a port-scoped relay credential with HMAC-SHA-256 and avoids adding relay credentials for unknown loopback ports. Tests assert that the derived relay value is not the Gateway token. This reduced the consequence of a relay probe without pretending hostile local tenancy had become supported.

Who had to act

The February sequence divided operators into three practical groups:

1. Sandbox-browser users below 2026.2.14 needed to upgrade or disable agents.defaults.sandbox.browser; container isolation alone did not protect the bridge.
2. Chrome extension-relay users below 2026.2.19 needed consistent token configuration on both relay sides. Shared-host users also needed 2026.2.22 or later so a CDP probe did not carry a reusable Gateway credential.
3. Operators automating intranet, metadata or local-file workflows had to stop assuming every previously reachable destination should remain reachable. Exceptions became explicit policy decisions, not incidental consequences of where Chrome ran.

We are not recommending those February builds today; they are historical milestones, not current version advice.

What this history explains today

The current browser documentation describes a dedicated managed profile as separate from the operator’s personal browser and presents signed-in-session attachment as a distinct, more sensitive mode. The current security documentation still defines one trusted operator boundary per Gateway and recommends separate Gateways—and ideally separate OS users or hosts—for adversarial users.

February explains both positions. Browser automation is not merely “Playwright with clicks.” It is a chain of authorities spanning Gateway RPC, local HTTP and WebSocket relays, CDP, container networking, navigation policy and authenticated sessions. The durable operating model is to isolate the browser profile, authenticate every bridge, minimise who shares the host, make private-network exceptions narrowly, and treat browser control as operator-level access.

Verification note: OpenClaw Academy checked the official releases, three GitHub security advisories, their linked fix commits, npm publication metadata and current upstream documentation on 23 July 2026. Historical behaviour and tests are attributed to upstream evidence. We did not install or independently reproduce the affected 2026.1–2026.2 packages.