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— ifbh --checkfails, 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 rawcurl/websockets.
Environment overrides (advanced)
OCM_CDP_BRIDGE_URL— override the managed bridge URL used bybh --checkwhenBU_CDP_WSisn't set. Default:http://192.168.100.1:9222.BU_CDP_WS— explicit CDP WebSocket URL. If set,bhuses it verbatim andbh --checkprobes the matching/json/versionon the same host:port.
Use these only to target a custom remote Chrome (debugging, dev VMs). In normal operation the defaults are correct.