Browser use

[nocturne mason]

OpenCLAW is wicked cool. I was wondering if there's a better browser tool than the one Open CLAW uses because it frequently struggles with browser use. I tried the browser use tool as well, and same issue. Separately, is there a computer use tool? That would also solve it because something that can move the mouse and take screenshots will have the ability to really do anything.

[onyx gorge]

Under the hood OpenClaw’s browser tool is basically “Playwright over Chrome DevTools (CDP)”. There isn’t really a strictly “better” general-purpose DOM browser automation stack than that right now — when it feels bad, it’s usually one of these:

1. Model/tool-calling quality (the model struggles to pick the right element/ref, or outputs malformed tool calls)
2. Snapshot/ref strategy (using stale refs, or snapshots that are too big/noisy)
3. Where the browser is running (sandbox vs host, anti-bot, missing real session/cookies)

Things to try that genuinely help

• Use the “interactive” role snapshot mode (much easier to click reliably):
  Docs: https://docs.openclaw.ai/tools/browser
  CLI example: openclaw browser snapshot --interactive --compact --depth 6
• Re-snapshot after every navigation / major UI change (refs are not stable across nav).
• Use the Chrome Extension Relay when sites are finicky (real Chrome tab, real profile/cookies):
  https://docs.openclaw.ai/tools/chrome-extension
  Key detail: you must click the extension icon on the tab so the badge shows it’s attached (“ON”).
• If you’re on Linux and Chrome/Chromium startup is flaky, this doc fixes a lot of it:
  https://docs.openclaw.ai/tools/browser-linux-troubleshooting

“Computer use” (mouse/keyboard + screenshots)?

Not as a first-class, built-in “drive the whole desktop with the mouse” tool today. OpenClaw leans toward structured tools (browser DOM refs, node-host routing, etc.) because raw mouse automation is fragile and has gnarly security implications.

That said, you can get parts of that workflow via:

• Screenshots/screen recording (and vision) depending on your setup (node host / optional skills like Peekaboo on macOS).
• A custom skill that uses something like Playwright (already), or OS automation (pyautogui/robotjs/etc.) if you really want full desktop control.

Quick questions so I can point you to the right fix

• What does “struggles” mean in your case: can’t start the browser, can’t click/type, or it clicks the wrong thing?
• What OS + openclaw --version?
• Are you using the managed openclaw profile, or the chrome extension relay?

If you paste one failing example (site + what step fails + any error text), I can suggest the exact snapshot/action pattern to make it reliable.

[nocturne mason]

It sometimes cannot understand and click on complex pages. And chrome extension fails to attach to popups

[onyx gorge]

Yeah, both of those are known pain points, but there are a couple of practical workarounds.

1) “Complex pages” (can’t understand / can’t click)

Most of the time it’s one of: (a) snapshot is too big/noisy, (b) the target is inside an iframe, (c) the DOM is shifting and your ref went stale.

Things that tend to make it dramatically more reliable:

• Use interactive + compact snapshots (smaller, click-focused):

• CLI: openclaw browser snapshot --interactive --compact --depth 6

• Even better for debugging: openclaw browser snapshot --interactive --labels (shows a screenshot with the ref labels overlaid)

• If it’s inside an iframe, you usually must snapshot the frame:

• CLI: openclaw browser snapshot --frame "iframe#something" --interactive

• (Otherwise the element often won’t appear in the ref list at all.)

• When a click fails, “highlight” the ref to see what Playwright thinks it’s clicking:

• CLI: openclaw browser highlight e12

Browser docs (snapshot modes / frames / labels): https://docs.openclaw.ai/tools/browser

If you paste one example site + what it’s trying to click, I can tell you whether it’s “needs --frame”, “needs selector scoping”, or “refs going stale”.

2) Chrome extension relay can’t attach to popups

That’s a limitation of the relay model: the extension attaches to a specific tab target (the one you clicked the toolbar button on). A popup is usually a different target/window, so:

• If the popup is a normal Chrome window/tab with a toolbar, you typically need to focus the popup and click the extension icon again to attach to that popup tab.
• If the popup is a “true popup” that doesn’t expose the normal extension UI (common in some OAuth flows), there may be nothing to click, so you can’t attach via the toolbar at all.

Workarounds:

• Use the managed openclaw browser profile for workflows that spawn popups (it can see new tabs without manual attach): https://docs.openclaw.ai/tools/browser
• Or try to make the site open auth in the same tab (some sites have a “continue in browser” / “use same window” option).

Chrome extension relay docs: https://docs.openclaw.ai/tools/chrome-extension

If you have a specific popup flow (e.g. “Sign in with Google on X site”), link it and I’ll suggest the least-annoying path for that class of popup.

[nocturne mason]

The openclaw profile is better but the issue with that is sessions don’t persist so I have to keep logging into whatever I need it to control

[onyx gorge]

The openclaw managed profile should persist logins — it uses a real Chrome user-data-dir on disk (so cookies/session storage survive restarts).

When people have to re-login every time, it’s usually one of these:

1. You’re actually controlling the sandbox browser, not the host-managed profile (sandbox is often “fresh” each run).
   Fix: allow host browser control (or disable sandbox) and explicitly target host:

• Config:

{
agents: { defaults: { sandbox: { browser: { allowHostControl: true } } } }
}

• Then use target:"host", profile:"openclaw" (or CLI: openclaw browser ... --target host)

2. Docker / ephemeral home volume: your ~/.openclaw isn’t persisted, so the browser profile resets with the container.

3. You’re re-creating/deleting the profile somehow (rare), which wipes the user data.

Quick sanity check: after you log in once, does it stay logged in if you just run openclaw browser stop → openclaw browser start?

If you tell me your setup (local install vs Docker vs remote gateway+node) + whether your agent is sandboxed, I can point to the exact knob to make the session stick. Docs that cover the sandbox gotcha: https://docs.openclaw.ai/tools/browser-login

[nocturne mason]

Oh I never have to run the openclaw browser command manually. It does that for me if I tell it to use the openclaw profile

[onyx gorge]

Yep — you normally don’t need to run openclaw browser ... manually; the agent will start it on-demand.

The “having to re-login” thing usually happens because you’re not always using the same on-disk browser profile:

The big gotcha: sandbox vs host

In sandboxed sessions, the browser tool often defaults to the sandbox browser (fresh/ephemeral), even if you say “openclaw profile”. That makes logins feel like they never stick.

Fix options:

1. Allow host browser control in config, then make sure the agent uses target=host:

{
agents: {
defaults: {
sandbox: {
browser: { allowHostControl: true }