Open Browser Use
Platform-neutral browser automation for AI agents, driving real Chrome through a CLI, multi-language SDKs, and MCP.
- Source repo
- iFurySt/open-browser-use
- Stars
- ★ 380
- Last updated
- 4d ago
- License
- MIT
- Primary language
- JavaScript
- FA score
- 36/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Developers already running Codex or Claude Code who want the agent to read live pages: install the open-browser-use skill with npx skills add and let the agent browse and summarize.
- Not a fit if
- Teams that need fully headless browser fleets with no Chrome or extension installed
- Users who want a hosted cloud service instead of registering a native host and extension per machine
- Source review
- 36/100 · Major gaps 2 safety controls not found
What does this agent do, and when should you use it?
Open Browser Use is a browser automation layer that stays neutral across agent runtimes, built from a Chrome extension paired with the open-browser-use CLI. It automates real Chrome over the Chrome DevTools Protocol and native messaging rather than launching a simulated browser. You can drive it from the CLI, from the JavaScript/TypeScript, Python, or Go SDKs, as an installable skill for Codex or Claude Code, or as an MCP stdio server via obu mcp. The workspace also ships open-browser-use-electron for embedded Electron browsers, with multi-tab task scopes, named profiles, private tool channels, and authenticated local sockets. It is released under the MIT license, with the CLI installable from npm or Homebrew.
The runtime has two halves: a Chrome extension and a local CLI that talk over native messaging. open-browser-use setup registers the native host and opens the Chrome Web Store page so the matching extension can be installed or enabled. On the agent side, the MCP server (obu mcp) exposes browser tools covering tab listing, opening, claiming, navigation, CDP calls, action plans, and cleanup. The SDKs mirror that surface: open-browser-use-sdk on npm, the same package name on PyPI (imported as open_browser_use), and the Go package under packages/open-browser-use-go (imported as obu). Actual automation runs against real Chrome via the Chrome DevTools Protocol. When the store listing is unavailable, open-browser-use setup beta prepares a keyed release ZIP for manual installation from chrome://extensions/, and setup --zip accepts an already-downloaded ZIP. Embedded Electron scenarios use the host-authorized obu iab mcp route instead.
- Developers already running Codex or Claude Code who want the agent to read live pages: install the open-browser-use skill with npx skills add and let the agent browse and summarize.
- Teams wiring browser capability into their own agent runtime: attach the MCP server with npx add-mcp or a manual obu mcp stdio entry.
- Engineering teams scripting page scraping, form interaction, or site checks: import the open-browser-use-sdk in Python, JavaScript/TypeScript, or Go directly.
- Electron desktop app builders who need multi-tab task scopes, named profiles, and an authenticated local socket through open-browser-use-electron.
- Organizations in restricted networks where the Chrome Web Store item is unavailable: use setup beta or setup --zip to distribute the keyed extension manually.
How do you install or deploy this agent?
Install the CLI globally and prepare the Chrome side:
# npm (macOS, Linux, Windows)
npm i -g open-browser-use
# Homebrew (macOS, Linux)
brew tap iFurySt/open-browser-use && brew install open-browser-use
# Upgrade
npm update -g open-browser-useRegister the native host; the command also opens the Chrome Web Store page so you can install or enable the matching extension, then restart Chrome if needed:
open-browser-use setupIf the Chrome Web Store item is temporarily unavailable, use the keyed manual path; a local ZIP can also be passed directly to skip the GitHub Release download:
open-browser-use setup beta
open-browser-use setup --zip /absolute/path/to/open-browser-use-chrome-extension.zipInstall whichever SDK you need:
# JavaScript / TypeScript
npm install open-browser-use-sdk
# Python
pip install open-browser-use-sdk
# Go
go get github.com/ifuryst/open-browser-use/packages/open-browser-use-goThe SDK package name is open-browser-use-sdk on both npm and PyPI; Python imports it as open_browser_use and Go imports it as obu. Building the embedded Electron workspace requires pnpm.
How do you use this agent?
Install the skill into Codex or Claude Code and invoke it through the agent:
# Install for Codex
npx skills add iFurySt/open-browser-use -g -a codex --skill open-browser-use -y
npx skills ls -g -a codex | rg 'open-browser-use'
codex exec --skip-git-repo-check "Use open-browser-use to check today’s Hacker News and summarize the most worth-reading posts."
# Install for Claude Code
npx skills add iFurySt/open-browser-use -g -a claude-code --skill open-browser-use -y
# Update an existing global install
npx skills update open-browser-use -g -yRegister the MCP server into all supported global agent configs, or declare the stdio MCP entry manually:
npx add-mcp "obu mcp" --name open_browser_use --all -g -y
npx add-mcp list -g[mcp_servers.open_browser_use]
command = "obu"
args = ["mcp"]The server exposes browser tools for tab listing, opening, claiming, navigation, CDP, action plans, and cleanup. For an embedded Electron browser, use the host-authorized obu iab mcp route instead. To try the Electron reference app:
pnpm install && pnpm example:iab
pnpm smoke:iabWhat are this agent's strengths and limitations?
- No runtime lock-in: the same browser capability ships as a CLI, JS/Python/Go SDKs, an agent skill, and an MCP stdio server.
- It automates real Chrome over the Chrome DevTools Protocol, so it reuses the user's actual sessions and extensions instead of a simulated browser.
- Concrete, ready-made integrations for Codex and Claude Code skills plus one-command global MCP registration via npx add-mcp.
- A documented fallback when the Chrome Web Store item is unavailable (setup beta, setup --zip) for restricted or offline distribution.
- MIT licensed, and it covers embedded scenarios through open-browser-use-electron with multi-tab scopes, named profiles, and authenticated local sockets.
- Requires a real Chrome install plus a version-matching extension and native host registration on each machine; it is not a server-side headless browser service.
- The Electron workspace feature is explicitly not yet published to npm, so using it means building from source with pnpm and running the reference app.
- The README acknowledges the store listing can be temporarily unavailable, leaving you to manage keyed manual ZIP installs.
- Available browser behavior depends on the extension version and Chrome-side changes, and no supported-version matrix is documented.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Open Browser Use This agent | 36 · Major gaps | CLIFree | ★ 380 | 4d ago | JavaScript | Codex · Claude Code |
| Open Claude in Chrome | 40 · Major gaps | MCP serverFree + model costs | ★ 254 | 26d ago | HTML | Claude Code |
| Obscura Headless Browser | 75 · Good | CLIFree | ★ 29k | 3d ago | Rust | Claude.ai |
| WebBrain | 65 · Some gaps | Browser extensionFree + model costs | ★ 1.5k | today | JavaScript | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence is limited to README claims of browser automation and CLI/SDK; no least-privilege rationale, user confirmation flow, data-flow transparency documentation, or sensitive-data handling policy is present. SECURITY.md remains a template with no real contact or response process. Dependency manifests exist but lack audit or vulnerability mitigation notes. Rollback is entirely absent. Scores are 1 or 0 accordingly; no red line found but evidence is thin.
README, package.json scripts, and CI workflow are broadly self-consistent, but failure-message design, dependency availability verification, and error-handling documentation are missing. CI only runs typecheck/test without demonstrating failure-message quality. Score 1.
README clearly targets multiple runtimes (Codex, Claude Code, MCP, Electron) with decent scenario coverage and environment fit (macOS/Linux/Windows, Homebrew, npm). However, capability boundaries and trigger precision are only scattered, not systematic. Audience gets 2, others 1.
README structure is clear, install steps are detailed, and MIT license is complete. But there is no changelog, no known-limitations section, naming stability is unaddressed (package name vs import name mismatch), and maintenance responsibility rests on a single individual. Information architecture and install get 2, others 1 or 0.
Output usability, marginal value, and cost-benefit are only asserted in README; no actual output examples, performance data, or comparative benchmarks are provided to verify advantage over alternatives. All 1.
Claims such as 'real Chrome automation' and 'no lock-in' lack supporting code or test evidence; cross-source corroboration is limited to README itself; fact and inference are not separated. All 1.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- SECURITY.md is a template with no real security contact or response process; it should not be treated as an effective security policy.
- No user confirmation, rollback, or sensitive-data handling documentation; browser automation may produce external side effects.
- Dependency manifests exist but lack audit or vulnerability mitigation evidence; supply-chain risk must be assessed independently.
- README capability claims lack code or test corroboration; static review cannot verify actual behavior.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Electron apps can now embed a multi-tab browser and let agents operate it through authenticated CLI or MCP connections. - Named profiles share login state; each task owns multiple independent tabs. - obu iab and obu iab mcp support inherited private channels and authenticated sockets with scoped, expiring grants. - The Electron SDK includes optional virtual cursor and configurable edge glow, plus a runnable example with tab switching, navigation, loading feedback and repeatable actions. …View on GitHub ↗ -
Release notes excerpt
What's Changed * feat(chrome): add WebMCP page tools by @mugnimaestra in https://github.com/iFurySt/open-browser-use/pull/18 * feat(chrome): add multi-query history search by @mugnimaestra in https://github.com/iFurySt/open-browser-use/pull/21 * Use connected targets for browser profile selection by @iFurySt in https://github.com/iFurySt/open-browser-use/pull/27 * feat(cli): support local extension ZIP in setup by @iFurySt in https://github.com/iFurySt/open-browser-use/pull/28 New Contributors …View on GitHub ↗ -
Release notes excerpt
What's Changed * Fix CLI JSON-RPC notification handling by @iFurySt in https://github.com/iFurySt/open-browser-use/pull/19 Full Changelog: https://github.com/iFurySt/open-browser-use/compare/v0.1.41...v0.1.42View on GitHub ↗