Bug type

Regression (worked before, now fails)

Summary

v2026.3.22 removed driver: "extension" and the relay WebSocket server. The replacement (existing-session / Chrome DevTools MCP) is host-local only and cannot work across machines. This breaks managed hosting providers who relied on the extension relay for remote browser control

Steps to reproduce

Steps to reproduce:

1. Run OpenClaw 2026.3.22+ on a remote server (Docker/VPS)
2. Install the Chrome extension relay (https://github.com/Yixn/clawhosters-relay)
3. Connect extension to remote instance via wss://
4. WebSocket connects (connect.challenge works) but no browser profile is created
5. Agent reports "user browser profile isn't connecting through the relay"

Expected behavior

In 2026.3.13 and earlier, the extension relay created a browser profile with driver: "extension" and the agent could control the user's remote Chrome via the relay WebSocket. This worked across machines without requiring Node.js, open ports, or CLI tools on the user's device.

Actual behavior

driver: "extension" rejected as invalid (only "openclaw", "clawd", "existing-session" accepted). The gateway still accepts the WebSocket connection and sends connect.challenge, but never wires it to a browser profile. The docs say existing-session is "host-local" only.

OpenClaw version

2026.3.24

Operating system

Mac Os

Install method

No response

Model

Doesnt matter

Provider / routing chain

doesnt matter

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: Managed hosting providers and their non-technical end users who use the Chrome extension relay for remote browser control. Specifically any OpenClaw deployment running on a remote server (Docker/VPS) where the user's browser is on a different machine.

Severity: High (blocks workflow - remote browser automation completely broken, no working alternative for non-technical users)

Frequency: Always (100% - driver: "extension" rejected by schema validation on every startup)

Consequence: Managed hosting customers lose the ability to let their AI control their local browser. The only alternatives require installing Node.js CLI tools or launching Chrome with special flags, which non-technical users cannot do. We had to deprecate the feature in our dashboard.

Additional information

I run ClawHosters (https://clawhosters.com), a managed OpenClaw hosting platform. Customers run instances on remote VPS servers.

We forked the Chrome extension as clawhosters-relay (https://github.com/Yixn/clawhosters-relay) specifically for this use case: non-technical users controlling their local Chrome from a remote OpenClaw instance.
One-click Chrome Web Store install, no CLI, no Node.js, no open ports.

The recommended alternatives don't work for managed hosting:

• existing-session: host-local only, can't cross machines
• Node host proxy: requires customers to install Node.js CLI on their machine (our users are non-technical)
• Remote CDP: requires Chrome launched with --remote-debugging-port and a tunnel (too complex for end users)

The extension relay was the only approach that worked for non-technical users on remote instances. A Chrome extension is a 1-click install. A Node.js CLI is not.

Could the extension relay be restored as a plugin or optional gateway feature?
The WebSocket endpoint (/extension with connect.challenge) still exists in the gateway code.
It just needs a profile driver to wire it to the browser tool.