An OpenClaw browser trial finds installed files are not a connected tab

Brax at ego published a September 10 hands-on account of OpenClaw Browser Relay that stops short of claiming a successful connection. The isolated macOS run installed the extension files and native-host registrations, then remained in manualSetupRequired because Chrome had not approved a supported extension identity. That is a useful failure report, not a demonstration that Relay cannot work. The author separately got the managed-browser control case healthy, showing why a green service check cannot stand in for a connected everyday browser.

The live official documentation supports this layered reading. It describes browser automation infrastructure rather than a chat sidebar, requires Chrome-side approval, and explicitly says local installer observations do not prove a live connection. It also allows a deterministic, path-verified development extension; the trial's failure with a different unpacked identity should not be read as a blanket ban on development installs.

The facts

- The trial used OpenClaw 2026.9.3 and reports that Node 22.12.0 was rejected; npm currently requires Node >=24.16.0 <25 or >=26.1.0. - The author reports an installed extension copy and four native-host registrations, but zero attached tabs. - The separate managed-browser control case passed seven doctor checks after its browser was started. - Official installer JSON separates Store requests, approval discovery, unpacked identity checks and native-host registration health. - Current documentation says the macOS installer neither restarts Chrome nor approves Chrome's permission prompt for the operator. - The author reports removing eight owned native-host artifacts after the test; this publication did not repeat that installation experiment.

Why it matters

Existing signed-in browser state is valuable precisely because it carries authority. Confusing an installed helper with permission to use a tab can produce either silent failure or pressure to weaken identity checks. The practical distinction is between service readiness, approved extension identity and the intended page becoming visible. Each is evidence for a different claim. A managed browser with a separate profile is a useful control experiment, but it does not inherit the accounts that motivated Relay in the first place.

Current

Inspected on 2026-09-11. The OpenClaw release baseline is 2026.9.3 on npm latest/beta; extended-stable is 2026.6.35 (registry checked today). The main source was author report dated September 10 when captured. Release metadata bounds availability; proposals, merged mainline changes and packaged releases are not interchangeable.

Evidence

Primary evidence: Brax at ego — September 10 Browser Relay trial (https://lite.ego.app/article/openclaw-browser-relay). Supporting context: OpenClaw — current Chrome extension installation and identity guide (https://docs.openclaw.ai/tools/chrome-extension); OpenClaw — managed and existing-profile browser control (https://docs.openclaw.ai/tools/browser). These pages were inspected directly. Linked documentation establishes the product contract; it does not independently reproduce contributor or author experiments.

Operator take

Use the official status and tab checks as separate acceptance steps, then verify one low-risk action on the intended page. Keep the account, profile and access mode explicit. Do not solve an identity mismatch by disabling the native-host restriction. This article is strongest as a troubleshooting sequence with a disclosed stopping point; its commercial browser comparison is not a neutral product benchmark.

Caveat

ego sells an adjacent browser product. The installation results are the author's report, not an independently repeated test. Current live documentation, rather than abbreviated cached extraction, defines the supported development path.