version: "1.0.0" name: ocm-browser description: Drive a browser from an OpenClaw machine. Companion to the browser-harness skill — explains the OCM-specific bridge proxy, the readiness check you must run first, and how pairing works. Start here before writing any browser code.

ocm-browser

OpenClaw machines don't run Chrome themselves. When you need a browser, a separate browser VM is paired with your machine and its Chrome is reached via a managed CDP bridge at http://192.168.100.1:9222. The browser-harness skill gives you the Python helpers (click, js, screenshot, new_tab, page_info, cdp) that talk to that Chrome.

Read this skill before writing browser code. Nothing below the readiness check below is usable unless the check passes.

Readiness check — ALWAYS run first

bh --check

Exit 0 means a browser VM is paired and reachable. Exit 1 means there is no browser to drive — stop, tell the user, do not claim you ran code you did not run.

The probe mirrors the endpoint bh will actually use, so a 0 exit here is a reliable green light.

Minimum happy-path example

bh <<'PY'
new_tab("https://example.com")
wait_for_load()
info = page_info()
print(info["url"], info["title"])
PY

All helpers come from the browser-harness skill. bh wires up the bridge CDP URL for you — you don't need to set BU_CDP_WS yourself.

When to consult interaction-skills

• interaction-skills/pairing-readiness.md — if bh --check fails, or if

the user asks "can I use a browser right now?"

• interaction-skills/bridge-proxy.md — if you need to understand what the

bridge does, what network it exposes, SSRF policy, or why a request is blocked.

• interaction-skills/browser-vm-lifecycle.md — if the user asks about

pairing/unpairing, what survives a VM restart, or how to restart Chrome without losing session state.

• interaction-skills/profile-persistence.md — if you need to save a

logged-in browser session (LinkedIn, X/Twitter, Instagram, Facebook, most SaaS) and restore it after the browser VM gets recreated or a new one is paired.

• browser-harness/interaction-skills/cookies.md — generic Browser Harness

cookie guidance.

Important constraints

• Cookies and session state live in the browser VM, not this machine.

They persist while the browser VM runs; they vanish if the user unpairs or recreates it. To keep them across unpair/recreate, save the cookie jar first — see interaction-skills/profile-persistence.md.

• The bridge has a fail-closed SSRF policy. Arbitrary internal IPs are

blocked; the bridge's own RFC1918 address is allowlisted by the platform.

• You do not have direct TCP access to the browser VM's Chrome. Always

go through bh / browser-harness, not through raw curl / websockets.

Environment overrides (advanced)

• OCM_CDP_BRIDGE_URL — override the managed bridge URL used by bh --check

when BU_CDP_WS isn't set. Default: http://192.168.100.1:9222.

• BU_CDP_WS — explicit CDP WebSocket URL. If set, bh uses it verbatim

and bh --check probes the matching /json/version on the same host:port.

Use these only to target a custom remote Chrome (debugging, dev VMs). In normal operation the defaults are correct.