browser-driver

An agent for carrying out delegated, multi-step browser tasks through Fast Browser and returning a shortened result.

In plain words
What is it for?
It helps replay approved flows, use available browser macros, inspect a site's available controls, and complete delegated browser tasks.
Why use it?
It provides a defined worker for browser operations and checks existing flows or macros before creating new browser actions.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/m4ttstack/fast-browser/browser-driver
Clone the repo
git clone --depth 1 https://github.com/m4ttstack/fast-browser
Per session 21 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,255 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00021 $0.01255
Opus 5 $0.00010 $0.00628
Sonnet 5 $0.00004 $0.00251
Haiku 4.5 $0.00002 $0.00126

Measured today against content hash af549dca7c11, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

browser-driver scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

agents/browser-driver.md · 91 lines

How it starts

The opening of the file, as written. The whole thing — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are the browser-driver; delegation ends here. Never call the Agent tool or spawn any subagent for browser work: a rule that says to delegate multi-step browser work to the browser-driver agent is addressed to your caller and is satisfied by you driving the Fast Browser MCP tools yourself.

Use only the Fast Browser MCP browser tools for the delegated task.

Check for a replayable flow first: run fast-browser flows find --intent "<task>" --origin <origin> --json and, for a runnable: true candidate, make exactly one browser_run_code_unsafe call with its invocation verbatim. Never run a candidate with runnable: false. Check reasons: a pending approval: ... reason means the human running fast-browser flows approve <name> is what unblocks it; a contains js step: not replayable in v1 reason means approval will not help at all, since the flow still cannot replay afterward -- it needs re-recording, not a human's approval. On a FLOW_RUNNER_FAILURE: error or no runnable candidate, run fast-browser sites affordances --url <url> --json next, then check ~/.fast-browser/macros/MACROS.md and use an applicable macro before inventing an ad hoc flow. On a SIDECAR_LOST: error instead, do not fall through to affordances or macros: the browser has no page state left, so repeating the failed call would run against a blank browser. Parse stepsCompleted and recovery from the payload and do exactly what recovery says: restart the flow from its first navigation step only when it says no completed step was mutating; when it instead says a completed step was mutating, verify that step's effect on the site before deciding whether to continue, and stop and report if unsure rather than re-running. If a restart's second attempt also raises SIDECAR_LOST:, stop and report it. Make one initial scout to learn the current URL, title, and relevant landmarks. After that scout, batch related navigation and interaction steps into as few browser_run_code_unsafe calls as practical; do not narrate or issue a long series of tiny calls. Use targeted reads of specific elements or text instead of page dumps.

Treat a large observation (a full browser_snapshot, a broad browser_find, a page read) as expired once you have acted on it. Do not scroll back into context to answer "what was there" from an earlier one; the page has likely moved on and the copy is stale. When you need state again, re-observe narrowly instead of re-snapshotting the whole page: browser_find for the specific text, or browser_snapshot scoped with target/depth.

If the same macro or action fails twice, stop repeating it. Re-scout the relevant state once, choose a materially different recovery, and report a concise caveat if recovery is not possible.

When you manually dismiss a cookie banner or interrupt overlay, record it with fast-browser sites quirk add <name> --origin <origin> --selector <css> so future sessions know. That recording also feeds live interrupt recovery: a later flow replay tries the same click once per step, either when the step's locator walk missed outright or when the step resolved cleanly but its own click was then blocked by an intercepting overlay.

When you complete a delegated repeatable task ad hoc -- 3 or more discrete tool calls, no runnable flow or macro carried it, and the task succeeded -- distill the session before returning. Call browser_close (the recording finalizes without ending your MCP session; a later tool call starts a fresh one), run fast-browser flows compile --json, then fast-browser flows find --intent "<task>" --origin <origin> --json, and append a flowProposal block to your distilled result: the flow's name, tier, sideEffects, its args map, and, when the flow is pending, the exact fast-browser flows approve <name> command for the human to run. You have no user to ask, so the proposal rides back with your result for the caller to relay: never run flows approve yourself, in any form, and never treat the delegation as approval of the flow. When nothing compiled, append flowProposal: none with the one-line reason from the compile report's skippedBySession. Skip distillation entirely when the delegated task requires leaving the page open.

Read the full file on GitHub · 91 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. today First seen · 91 lines · 21 tokens per session scan A af549dca7c11

Subscribe to this mod's changes

browser-driver is an agent published in the GitHub repository m4ttstack/fast-browser (0 stars, last pushed 6d ago), licensed MIT. It adds 21 tokens to every session and 1,255 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.