# Browser

> Drive a real web browser the user logs into - open pages, read content, search, fill forms, click, and act in the user's authenticated sessions (social media, dashboards, any site). Use when a task needs a live browser: 'go to <site>', 'search X on <site>', 'log into my <account> and do Y', 'check my messages/notifications', or automating a site that needs a real logged-in session. NOT for previewing this project's own dev server (that's the Browser drawer) and NOT for a one-off screenshot of a public URL (use scripts/browser.mjs).

- Skill: `futrx-com/browser` (Agent Skill)
- Install (CLI): `npx skillmds@latest add futrx-com/browser`
- Raw SKILL.md: https://api.skillmd.com/api/skills/futrx-com/browser/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: futrx-com (https://skillmd.com/u/futrx-com)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/futrx-com/browser

---


# Browser

You can drive a real Chromium running inside this container. With this skill
active, the browser core starts automatically and you have `browser_*` MCP
tools attached over CDP to the live shared session. If the user opens the
Browser pane, they see the same browser and can log in by hand; you inherit
that session's cookies without handling credentials.

This skill is for the **Live Agent Browser** only. For one-off public
screenshots, recordings, or cookie-authenticated headless recipes, use
`/workspace/scripts/browser.mjs` instead.

## How to work
Use a hybrid perception loop:

1. `browser_navigate`, then `browser_snapshot`. The snapshot is the default
   way to read structure, text, roles, and element refs.
2. Take a screenshot when the task is visual: layout verification, charts,
   maps, canvas, image content, custom widgets, anything opaque or missing
   from the snapshot, and after actions with visible consequences.
3. Act through refs when the snapshot gives reliable targets. Use
   screenshot-grounded coordinate interaction when the DOM is misleading.
4. Observe again after each action with `browser_snapshot`,
   `browser_take_screenshot`, or `browser_wait_for`. Do not assume an action
   worked.

Keep screenshot cost bounded: viewport screenshots by default, JPEG/moderate
quality when options are available, full-page screenshots only when needed.
The viewport is 1366x768 and maps 1:1 to OS-level fallback coordinates.

## Pacing

Wait for navigation/load states before acting. Use `browser_wait_for` when
content is dynamic. Take one meaningful action, then observe. Avoid blind
multi-action bursts, especially on authenticated sites.

## Logging in

This browser exits via the container's datacenter IP, so strict providers may
show verification challenges. If a task needs a login or challenge response:

1. Ask the user to open the Browser pane and log in by hand.
2. Wait until they say the login is complete.
3. Continue with the `browser_*` tools against the shared session.

Never type the user's credentials yourself.

## OS-level input fallback

Use the `browser_*` tools first. If a site visibly swallows or rejects CDP
input, fall back to X-server input with coordinates from a screenshot:

```sh
sh /workspace/.browser-gui/human-input.sh move 640 420
sh /workspace/.browser-gui/human-input.sh click 640 420
sh /workspace/.browser-gui/human-input.sh type "text to type"
sh /workspace/.browser-gui/human-input.sh key Tab Return
sh /workspace/.browser-gui/human-input.sh scroll -3
```

Coordinates map to the browser window at 0,0 on the 1366x768 display.

## Write policy

Reading (search, timelines, messages) is fine on your own. Before any public
or irreversible write - posting, replying, DMing, following, buying, or
changing settings - say exactly what you're about to do and get the user's
confirmation first. They can watch and stop you in the Browser pane.