open source · agent-native browser use
Give your agent keys to the web.
browauth turns logged-in browser workflows into typed, reusable commands. Authenticate once, then read views and run actions as structured JSON — no API keys, no pixel-hunting, a fraction of the tokens.
// the problem
Stop paying your agent to squint at screenshots.
Generic browser agents navigate the web like a tourist reading a map through a keyhole — screenshot, guess, click, repeat. browauth gives them the paved road: one typed command in, structured JSON out.
pixel-hunting agent
- 1.screenshot the page
- 2.send 2 MB of pixels to the model
- 3.guess where the button is
- 4.click. miss. screenshot again
- 5.…repeat × 14
0
tokens
0
round trips
0s
seconds
browauth
❯ browauth view read gmail.inbox --limit 3 --json
{ "count": 3, "items": [...] }
0
tokens
0
round trips
0s
seconds
* illustrative run: reading three inbox rows with a screenshot-driven agent vs one declarative view. your mileage will be better.
// primitives
Three verbs. The whole web.
Sites hold auth. Views read. Actions do. Every site package composes the same three verbs, so your agent learns the pattern once and reuses it everywhere.
Auth as a contract
A site package declares how login works and what a logged-in page looks like — landmarks, success conditions, a typed recipe. Your agent asks for the outcome; browauth handles the account picker, the SSO dance, the password fill.
- Credentials are 1Password references — never stored, never printed
- Google SSO chains: sign into Gmail once, GitHub and Medium follow
- One identity = one Chrome profile = one CDP port. No cookie soup
❯ browauth site ensure github --json
✓ google sso via authenticated session
{ "site": "github", "logged_in": true }
// site packages
Packages for the sites you already live in.
One file per site: auth recipe, views, actions, catalog metadata. Core packages ship with the binary; drop your own into ~/.browauth/sites.d and it loads like a first-class citizen.
gmail.json
coreproductivity
- ▸ gmail.inbox
- ▸ gmail.search_results
- ▸ gmail.search
github.json
coredeveloper
- ▸ github.repositories
- ▸ github.open_repo
- ▸ github.trending_repos
medium.json
corecontent
- ▸ medium via google-sso
- ▸ landmark-verified sessions
amazon_ca.json
live-validatedecommerce
- ▸ product.search
- ▸ product.detail
- ▸ read-only smoke tests
Yours takes about four minutes.
Scaffold a package, add a view with field selectors, validate, done. Smoke-test it read-only before your agent ever touches it.
❯ browauth site init yoursitecommunity-maintained packages — proposed, incoming, or waiting for you to write them
// safety
Safe by construction, not by prompt.
Every action declares a safety class before it can exist. The dangerous ones fail closed — before a single browser mutation — unless a human said --yes.
secrets policy
❯ browauth credential get gmail --field password
{ "password": "sha256:9f2c… (len 18) — redacted" }
Config stores 1Password references, never values. Passwords never touch argv, stdout, logs, or your model's context window. secret_fill reads them only inside browauth's local execution path.
read_only
gmail.search
navigational
github.open_repo
draft
gmail.compose_draft
external_send
gmail.send
destructive
github.delete_repo
every failure returns structured diagnostics — current URL, matched/missing conditions, sanitized steps — so agents repair recipes instead of flailing.
// install
In your terminal in ten seconds.
One binary, one skill file. Install the CLI, teach it to your agent, and it starts preferring typed commands over pixel-hunting on its own.
01 install the cli
02 teach your agent
03 hand over the keys
❯ browauth doctor --json
✓ agent-browser ✓ op ✓ config — ready
Human-in-the-loop, when it matters. Approve an --yes-gated action from your desk or your phone — the browauth desktop app handles 2FA prompts, consent screens, and anything an agent shouldn't decide alone.
The web is yours. Hand your agent the keys.
MIT licensed · built on agent-browser · secrets stay in 1Password