browser-outo
Let AI agents drive YOUR real browser — the one you're already logged into.
browser-outo is a CLI + browser extension that gives AI agents (Claude Code, OpenCode, or any script) full control over your actual Chrome or Firefox: open tabs, read pages, click, type, scroll, screenshot, and more. Everything runs 100% locally — your cookies, sessions, and credentials never leave your machine.
- No cloud browser, no fresh profile. The agent uses your browser with your logins, your cookies, your reputation. Sites that bot-drive browsers can't touch (CAPTCHAs, login walls, Cloudflare) just work — reCAPTCHA v2 passes with a single click on a well-used profile.
- No automation fingerprint. Nothing is injected into the page before you
say so, and there's no
navigator.webdriverflag. Commands run through a normal browser extension, not an automation driver. - Fully local. The CLI uses token-authenticated HTTP to a local server on
127.0.0.1:11681, and the browser extension connects to that server over WebSocket. No telemetry, no external calls.
How it works
┌─────────────┐ HTTP + token ┌──────────────────┐ WebSocket ┌─────────────────┐
│ browser-outo│ ◄────────────► │ local server │ ◄─────────► │ browser │
│ CLI (agent) │ │ 127.0.0.1:11681 │ (outbound) │ extension │
└─────────────┘ └──────────────────┘ └─────────────────┘
Run browser-outo serve to start the local server. The CLI sends commands to
it over HTTP with a bearer token, and the extension opens an outbound
WebSocket connection to it. Multiple browsers can connect at once, and each
gets a numeric EXT_ID you target per command.
Security and limitations
Each server start creates a fresh bearer token in a per-user state directory.
The directory is mode 0700, and the token file is mode 0600. API requests
require the token, the WebSocket accepts only extension origins, and the server
stays on loopback unless you pass --allow-remote.
A process running as the same user can kill the server, bind to its loopback port, and impersonate browser-outo to an extension that connects afterward. This is a known, accepted limitation of the local WebSocket architecture.
Install
1. The agent skill (teaches your AI agent how to drive it and installs the CLI when needed):
npx skills add llaa33219/browser-outo
2. The browser extension is coming soon to the Chrome Web Store and Firefox Add-ons.
3. Start the local server:
browser-outo serve
The server listens on 127.0.0.1:11681. Leave it running while browser-outo
is in use. The extension connects automatically, though its retry loop means
the first connection after a restart can take a few seconds.
Then ask your agent to open pages, fill forms, read content, or take screenshots. The agent handles every command through the skill.
It works inside iframes too. Elements from all frames are merged into one numbered list, and clicks route to the right frame automatically.
Why not browser-use / Playwright / Chrome MCP?
All four tools are local software with CLI/skill-based agent interfaces — the honest differences are what browser you end up driving, and where your page data goes:
| browser-outo | browser-use | Playwright (CLI/MCP) | Claude for Chrome | |
|---|---|---|---|---|
| Your live browser session (same profile, same tabs, while you keep browsing) | ✅ the default — one extension, zero browser-side setup | ❌ since Chrome 136 CDP is blocked on your real profile — you must automate a copied profile and log in again there | ❌ same Chrome 136 block; otherwise launches its own Chromium/Firefox/WebKit build, not your browser | ✅ |
| "Being debugged" infobar | ✅ never (no debugger API) | ✅ none | ✅ none | ❌ shows (uses chrome.debugger) |
| Page data leaves machine | never — localhost only | → whatever LLM you configure | → your MCP client's LLM | → Anthropic API (screenshots/content) + usage data |
| Agent interface | any CLI-capable agent (SKILL.md included) | CLI + skills, or its own LLM agent loop | playwright-cli + skills, or MCP server | Claude only |
| Browsers | Chrome and Firefox, simultaneously | Chromium (CDP) | launches Chromium/Firefox/WebKit; attaching to your existing browser is Chromium-only | Chrome only |
| Cost | free, Apache-2.0 | free, open source | free, open source | paid Claude plan required |
(LLM costs for the driving agent apply equally to all four — the only mandatory extra is Claude for Chrome's subscription.)
The short version: since Chrome 136 killed remote debugging on real profiles, CDP-based tools can only drive a copy of your browser — a separate profile that drifts out of sync with your daily one. Claude for Chrome is the closest in spirit, but it ships your page content to Anthropic, flashes a debugging banner, and requires a paid plan. browser-outo drives the browser you're literally using right now, from any agent — no fingerprint, no banner, no profile copies, no lock-in.
For AI agents
The skill source lives in skills/browser-outo/SKILL.md (installed via
npx skills add llaa33219/browser-outo). It teaches the agent the full
command set, the elements→interact loop, the annotate→vision loop, and the
pitfalls (stale indices, restricted pages, trusted-event sites).
License
Apache-2.0
Release files for browser-outo 0.3.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| browser_outo-0.3.0.tar.gz | 17.0 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| browser_outo-0.3.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 36.5 kB
Release files / browser_outo-0.3.0.tar.gz
| Download URL | browser_outo-0.3.0.tar.gz |
|---|---|
| Size | 17.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
8ca6619cb2e487f74db6530470aec26e7e7aee4d0b5783b8c288d063435017d8
|
|
BLAKE2b-256 checksum How to use checksums |
2dca62e686e434d421163c32b23eb7b99758a755e4bba03ae196b4000280e755
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 29, 2026.
Transparency logRelease files / browser_outo-0.3.0-py3-none-any.whl
| Download URL | browser_outo-0.3.0-py3-none-any.whl |
|---|---|
| Size | 19.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5b7ab3c6f6eab5e7bb564014fdbf9ef95400229d0074f6d9a04a73b6a0cfd455
|
|
BLAKE2b-256 checksum How to use checksums |
00f43a5674b91f46d70cefa870954565a53f928e680f1b89ffb2bc073df9c6ad
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 29, 2026.
Transparency log