hive.browser-automation

# GCU Browser Automation

All GCU browser automation drives a real Chrome instance through the Beeline extension and Chrome DevTools Protocol (CDP). You drive it **from the terminal**: every command is `hive-browser <command> ... --json`, run through `terminal_exec`. Always pass `--json` so the result is machine-readable. That means clicks, keystrokes, and screenshots are processed by the actual browser's native hit testing, focus, and layout engines — **not** a synthetic event layer. Understanding this unlocks strategies that make hard sites easy.

## Browser lifecycle & recovery — read this before "fixing" anything

The bridge attaches to the **user's already-running Chrome** via the extension. The browser is not yours: it holds the user's logged-in sessions and other agents' work, and the runtime — not you — owns the connection to it. Consequences:

- **There is nothing to "start."** If no browser is connected, `hive-browser setup --json` tells you and gives the user install steps. Launching Chrome yourself (any `google-chrome`/`chromium` command, `--remote-debugging-port`, `--user-data-dir`, headless flags) is forbidden and blocked — it opens a browser the bridge can't see, often under the wrong profile.
- **There is no situation where killing the browser helps.** Never use terminal tools to `kill`/`pkill`/`killall` Chrome, the bridge, or gcu processes. These commands are blocked, and attempting them breaks every agent sharing the connection. The same applies to the Hive desktop app and `bridge_host`.
- **A timeout is NOT a stuck browser.** All `hive-browser` commands share one transport across all agents; one slow call (a heavy `hive-browser evaluate` on a big page) can make YOUR calls time out while the browser is perfectly healthy. The timeout message tells you whether the server passed its liveness check and whether recovery is already running — believe it.
- **Allowed recovery, in order:** (1) wait ~30s and retry ONCE, with a smaller/simpler request — e.g. split a page-wide `hive-browser evaluate` sweep into chunked queries; (2) close YOUR OWN tabs with `hive-browser tab close <T> --json` and reopen; (3) report the failure (`report_to_parent` or your reporting channel) and move on to work that doesn't need the browser. Escalate to the user; never to the process table.
- Keep heavy `hive-browser evaluate` scripts cheap: avoid `innerText` over thousands of nodes (each read forces layout). Prefer `textContent`, scope the selector, and paginate the sweep.

## Targeting a specific Chrome profile / account

If your machine has more than one Chrome profile connected (different logged-in accounts), **say which one to act in** — if you omit it, the bridge falls back to the first-connected profile, which may be the wrong account. Pass `--browser-profile <label>` to `hive-browser open` (and `hive-browser navigate` / `hive-browser script`):

- **See every connected profile** in `hive-browser status --json` / `hive-browser setup --json` — both return a `connected_profiles` list of `{label, is_default, starred}` for ALL connected Chrome profiles (not just the one you're using). That's how you discover the labels. (`hive-browser status` reflects ALL connections; don't conclude "only one profile" from the single profile label of your own context.)
- The label is a **connected profile label** — the name shown in that profile's Hive extension side panel (or its auto 3-word id). If your task assigns you a profile (e.g. *"your profile is `acct-jpn`"*), pass exactly that.
- Every command's JSON echoes the profile it **actually** used. Check it: if it doesn't match what you intended, you opened the wrong account. Stop and fix the label (don't proceed).
- A label that isn't connected fails fast with the list of connected labels — bind to one of those.
- With one profile connected (or one starred default), you can omit it. With several connected and no star, omitting it uses the **first-connected** profile — fine for single-account work, risky for multi-account, so pass the label when the account matters.

## Working on LinkedIn?

For ANY LinkedIn flow, load `hive.linkedin-core` first — it owns the auth check, rate limits, stop protocol, reply-text policy, and DOM gotchas every LinkedIn script depends on. Then load the capability skill for the task: `hive.linkedin-discovery` (scans / People search), `hive.linkedin-messaging` (`lk_send_to_message_url`, `reply`, inbox), `hive.linkedin-connect` (`lk_send_invite`, post comments), or `hive.linkedin-sales-navigator` (premium search + InMail).

## Coordinates

Every `hive-browser interact` action that takes a `--coordinate` — and every command that returns one — operates in **fractions of the viewport (0..1 for both axes)**. Read a target's proportional position off `hive-browser screenshot` — "this button is about 35% from the left and 20% from the top" → pass `--coordinate 0.35,0.20`. Rect-returning commands (`hive-browser page shadow-query` and the `rect` inside `focused_element`) also return fractions. The CLI converts to CSS pixels internally before dispatching to Chrome.

```
hive-browser screenshot --json                                      → image + cssWidth/cssHeight in meta
hive-browser interact --action left_click --coordinate x,y --json   → x, y are fractions 0..1
hive-browser interact --action hover --coordinate x,y --json        → fractions
hive-browser interact --action key --coordinate x,y --text k --json → fractions
hive-browser page shadow-query "<selector>" --json → rect           → rect.cx / rect.cy are fractions
```

**Exception for zoomed elements:** pages that use `zoom` or `transform: scale()` on a container (LinkedIn's `#interop-outlet`, some embedded iframes) render in a scaled local coordinate space. `getBoundingClientRect` there may not match CDP's hit space. Prefer `hive-browser page shadow-query` (which handles the math and returns fractions) or visually pick coordinates from a screenshot. Avoid raw `hive-browser evaluate` + `g