Use when controlling web pages with the OpenClaw browser tool, especially multi-step flows, login checks, tab management, or recovery from stale refs/timeouts.
Installs into .claude/skills of the current project.
Are you the author of Browser Automation?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/karanmrn-browser-automation)
---
name: browser-automation
description: Use when controlling web pages with the OpenClaw browser tool, especially multi-step flows, login checks, tab management, or recovery from stale refs/timeouts.
user-invocable: false
---
# Browser Automation
Use this skill when you need the `browser` tool for anything beyond a single page check.
## Operating Loop
1. Check browser state before acting:
- `openclaw browser doctor` or `action="status"` when the browser/plugin setup itself may be broken.
- `action="status"` for availability.
- `action="profiles"` if login state or profile choice matters.
- `action="tabs"` before opening a new tab if retries/timeouts may have left windows behind.
2. Prefer stable tab handles:
- Open important tabs with `label`, for example `label="meet"`.
- After `action="tabs"` or `action="open"`, store `suggestedTargetId` and pass it as `targetId` in later calls.
- `suggestedTargetId` is the label when one exists, otherwise the stable `tabId` handle like `t1`.
- Avoid relying on raw DevTools `targetId` except for immediate diagnostics; it can change under Chromium target replacement.
3. Read before you click:
- For “read the page and answer X,” use a selector-scoped `action="snapshot"` or `act:evaluate` that returns only relevant text or structured data. Let the active agent model answer from that bounded result; use efficient snapshots for controls and action discovery because they omit most non-interactive prose.
- For virtualized lists, scroll through each segment, capture only the relevant rows, then merge the results.
- Use `action="snapshot"` on the intended `targetId`.
- Use the same `targetId` for follow-up actions so refs stay on the same tab.
- For durable Playwright refs, request `refs="aria"` when supported. If you receive `axN` refs from `snapshotFormat="aria"`, use them only after that same snapshot call; stale or unbound `axN` refs fail fast and need a fresh snapshot.
- Use `urls=true` when link text is ambiguous or a direct navigation target would avoid brittle clicks.
- Use `labels=true` on snapshot or screenshot when visual position matters. On Playwright-backed profiles, the response includes an `annotations` array (`{ref, number, role, name?, box}`) with each ref's bounding box in the captured image's coordinate space, so you can reason about position without re-snapshotting; screenshot labels can also combine with `fullPage=true` (CLI: `--full-page`) to label the whole document, or `ref` / `element` to clip to one element. `profile="user"` and other existing-session (chrome-mcp) profiles render an overlay into page screenshots but do not attach `annotations` or use the Playwright full-page/ref/element projection helper, so read positions from the labeled image itself on those profiles. The raw-CDP fallback (no Playwright) does not support labeled screenshots at all and returns a 501, so only request `labels` when Playwright is available.
4. Act narrowly:
- Prefer `action="act"` with a ref from the latest snapshot.
- `navigate` returns the loaded page's compact snapshot inline, and batch `act` results that report a cross-document navigation include fresh page state; use those refs directly instead of a follow-up snapshot call.
- After a single act that triggers navigation, and after modal changes or form submissions, snapshot again before the next action.
- Avoid blind waits. Wait for visible UI state when possible.
5. Report real blockers:
- If the page needs login, permission, captcha, 2FA, camera/microphone approval, or another manual step, stop and tell the user exactly what is needed.
- Do not claim the browser is not logged in just because the current page shows a permission or onboarding dialog. Inspect the visible UI first.
## Browser batch CLI
`openclaw browser batch` runs an array of nested `/act` actions in one `/act` call (the same `kind="batch"` runtime reached through the agent tool), so CLI users and scripts can combine actions like `wait`, `click`, `type`, and `evaluate` into a single replayable plan without per-action round trips. Each entry in `actions[]` is a `BrowserActRequest` — the closed union the `/act` route accepts — not arbitrary `openclaw browser` subcommands. `batch` is not supported on `profile="user"` and other existing-session (chrome-mcp) profiles; send actions individually there.
- CLI: `openclaw browser batch --actions '<json>'`, `--actions-file plan.json`, or `--actions-file -` for stdin. `--continue` sets `stopOnError=false`; default stops on first error.
- Ref lifecycle: refs come from a `snapshot` run before the batch (snapshot is not a nested action). A nested action that changes page state — such as a `click` that triggers navigation, or an `evaluate` that mutates the DOM — can invalidate earlier refs for the rest of the batch; put state-changing actions first, or split into a follow-up batch after re-snapshotting. Navigation and re-snapshotting happen outside the batch, since `open`, `navigate`, and `snapshot` are not `/act` kinds.
- Target id: nested actions share the request's tab; an explicit nested `targetId` that resolves to a different tab is rejected with `ACT_TARGET_ID_MISMATCH`.
- Response: `{ "results": [{ "ok": true } | { "ok": false, "error": "..." }, ...] }` in order; with default `stopOnError` the array ends at the first failure. Any failed entry exits nonzero; use `--json` to preserve the full response in scripts.
## Code Mode Loop
When `tools.codeMode` is enabled, call the Browser tool from exec cells:
```javascript
const browserTool = "openclaw:browser:browser";
let previousSnapshot = "";
const callBrowser = async (input) => await tools.call(browserTool, input);
```
Keep the same labeled tab through the loop, and alternate reads with actions:
```javascript
const snapshotCall = await callBrowser({
action: "snapshot",
targetId: "task",
refs: "aria",
interactive: true,
});
const details = snapshotCall?.result?.details ?? {};
const snapshot = (snapshotCall?.result?.content ?? []).map((block) => block?.text ?? "").join("\n");
const relevant = snapshot
.split("\n")
.filter((line) => /submit|dialog|error|\[new\]/i.test(line))
.slice(0, 12);
const changed = snapshot !== previousSnapshot;
previousSnapshot = snapshot;
return { targetId: details.targetId, url: details.url, relevant, changed };
```
- Request interactive-only snapshots and filter them in code before returning.
- Return only the handful of relevant elements; never return the full tree.
- Keep `previousSnapshot` between cells when a local diff helps explain a change.
- Interleave each act with a URL or tabs check before the next dependent act.
- If a batch returns `aborted`, take a fresh snapshot before continuing.
- If `[new]` markers appear, inspect those elements first, then update the saved snapshot.
- Use separate act calls when navigation is expected between steps.
## Tab Hygiene
Before creating a tab for a named task, list tabs and reuse an existing matching label or URL when it is still usable.
Example:
```json
{ "action": "tabs" }
```
If no suitable tab exists:
```json
{ "action": "open", "url": "https://example.com", "label": "task" }
```
Then target it by label:
```json
{ "action": "snapshot", "targetId": "task", "refs": "aria" }
```
If a retry creates duplicates, close the extras by `tabId`:
```json
{ "action": "close", "targetId": "t3" }
```
Do not pass bare numbers like `"2"` as `targetId`. Numeric tab positions are only for the CLI `openclaw browser tab select 2` helper; browser tool calls need a `suggestedTargetId`, label, `tabId`, or raw target id.
## Stale Ref Recovery
If an action fails with a missing or stale ref:
1. Snapshot the same `targetId` again.
2. Find the current visible control.
3. Retry once with the new ref.
4. If the UI moved to a blocker state, report the blocker instead of looping.
## Existing User Browser
Use `profile="user"` only when existing cookies/login matter. This attaches to the user's running Chromium-based browser.
On macOS, `action="importprofile"` is the alternative when the agent should use an isolated managed browser with cookies copied from a real Chrome-family profile. First use `action="profiles"` and inspect `systemProfiles`, then import into a fresh managed profile name. Import asks for one Keychain/Touch ID consent prompt. It copies cookies, not local storage or IndexedDB; device-bound session credentials (DBSC) mean some Google sessions may still require re-authentication.
For `profile="user"` and other existing-session profiles, omit `timeoutMs` on `act:type`, `hover`, `scrollIntoView`, `drag`, `select`, and `fill`; that driver rejects per-call timeout overrides for those actions. `act:evaluate` accepts `timeoutMs`.
## Google Meet Notes
When creating or joining a Meet:
- Treat camera/microphone permission screens as progress, not login failure.
- If asked whether people can hear you, click the microphone option when voice is required.
- If Google asks for sign-in, 2FA, account chooser confirmation, or permission that needs user approval, report the exact manual action.
- Use one labeled tab per meeting flow, for example `label="meet"`, and reuse it during retries.