Yes, for a small team, but only with its guard rails switched on. agent-browser has no telemetry we could find and its license is plain Apache-2.0, yet a fresh install lets the agent open any site, run JavaScript in the page and read cookies and local storage, and a page it visits can send data to any other server.
Our take for small teams
We would use it, and we would never run it with the defaults on a browser that holds a real login. In our sandbox the stock install let a hostile test page push a token to a second server, and adding one flag (--allowed-domains) stopped that and also refused a loopback address we had not listed. The action policy needs care too: the example in the security doc denies an action called eval, but in 0.42.0 that name blocked nothing, because the code calls the action evaluate, so test your policy file before you trust it. Compared with driving your own Chrome over its debug port, it gives you a deny list, a domain list, output wrapping and an encrypted login vault that you would otherwise build yourself, so the extra tool is worth it once those are set. Use a named session per agent and a throwaway profile, and keep it away from your everyday browser profile.
Code license
Apache License 2.0
Commercial use
Yes
Your content leaves by default
No
Telemetry
None documented
Model weights
No weights shipped
Last checked
November 10, 2026
Picked from GitHub Trending (daily, weekly) on November 9, 2026, with 48,139 stars on November 9, 2026. Repository: vercel-labs/agent-browser.
agent-browser is a native Rust command line tool from Vercel Labs. An agent calls short commands such as open, snapshot, click and fill, and the tool drives a Chrome it manages itself. A snapshot lists the page as numbered refs (e1, e2, e3) so a model can act on them without reading raw HTML.
The risk is what the agent can reach, not what the tool phones home. It can read cookies and local storage, run script in the page, and keep a background daemon alive between commands. Four settings decide your exposure: the domain allowlist, the action policy, whether saved state is encrypted, and the Chrome version check.
The numbers
GitHub numbers fetched Nov 10, 2026, 04:57 UTC from the GitHub API.
Stars
48,636
Forks
3,312
Open issues and pull requests
537
Main language
Rust
Repository created
January 11, 2026
Last push
November 10, 2026
Last commit on the default branch
November 9, 2026
Latest stable release
v0.42.0, November 10, 2026
Archived
No
License
Code license
Apache License 2.0 (GitHub reports Apache-2.0)
Commercial use of the code
Yes
Model weights license
No weights shipped
LICENSE file read on
November 10, 2026
LICENSE read on 10 November 2026 at commit e751995: the Apache License, Version 2.0 text with the copyright placeholder left unfilled. Open the LICENSE file. This is our reading of the file on that date, not legal advice.
The LICENSE file is the Apache License 2.0, which allows commercial use, modification and redistribution with notice, and includes a patent grant. [1][2]
The npm package agent-browser declares Apache-2.0 for version 0.42.0, matching the repository. [1][3]
The repository ships axe.min.js, an unmodified build of Deque's axe-core used for accessibility audits, with the MPL-2.0 text and a third-party notice file next to it. The rest of the code is Apache-2.0. [5][6]
What you have to do
Keep the license text, and mark files you changed if you redistribute them.
The Apache license does not grant trademark rights.
The package carries a vendored copy of Deque's axe-core under MPL-2.0, which has its own file-level terms if you modify that file.
Model weights
agent-browser ships no model weights and no model runs inside it. The loop lives in your agent, which decides each command. The optional chat command and dashboard chat call a model through Vercel's AI Gateway only when you set AI_GATEWAY_API_KEY. [4][7]
The browser it downloads is Chrome for Testing, a separate Google build with its own terms. Browser pages you open are governed by their own terms. [8][9]
Where your data goes
The tool runs on your machine. The hosts its code calls are Google (the browser download and the Chrome version check), the npm registry (the upgrade command), Vercel's AI Gateway (chat and the doctor network probes) and a cloud browser provider only when you use that feature. What the pages you visit receive is another matter: by default the agent can send anything the page can read to any server.
Runs on your own machine or server
Yes
Your content leaves it by default
No
The npm package contains the native binaries for macOS, Linux and Windows (about 133 MB unpacked), so the npm install itself fetched nothing apart from the registry. A separate agent-browser install step then downloads Chrome for Testing: it reads the version list from googlechromelabs.github.io and then fetches the zip from storage.googleapis.com. [8][9]
On launch it starts Chrome headless with --disable-background-networking and --disable-sync, a throwaway user-data directory under /tmp and a remote debugging port picked by the OS. [10][4]
Every session automatically starts a WebSocket server on 127.0.0.1 at an OS-assigned port, for live viewing and input. The docs say browser clients must come from localhost or file origins, and in our test a handshake with no Origin header was accepted while one from another origin got a 403, so any local process can attach to it without a token. [11][17]
Navigation, action and output controls are all opt-in. Without them there is no limit on domains, no action policy, and page content is returned as plain text. The security doc says so directly. [12][4]
The domain allowlist (--allowed-domains) blocks navigations and, best effort, sub-requests, WebSocket and EventSource connections from the page. The docs state it is not an operating-system firewall, it relies on an injected script, and it is rejected together with --cdp, --profile, --auto-connect and --state. [12][13]
The action policy is a JSON file of allow and deny rules by action category. The security doc example denies eval, download and upload, but the code names the action evaluate, so a policy that lists eval does not block it in 0.42.0. Download and upload match the docs. [12][15][16]
state save writes cookies and local storage to a JSON file. The configuration doc describes AES-256-GCM encryption as something you enable with AGENT_BROWSER_ENCRYPTION_KEY, and without it the file we saved was plain text readable by anyone with access to the folder. The auth vault is different: it always encrypts, keeps its key in ~/.agent-browser/.encryption-key and shows the agent only names and URLs. [14][9]
Chrome is started with --no-sandbox automatically when the CI variable is set, when running as root, or inside a container. That is convenient for pipelines, and it also means a developer with CI=true in their shell runs the browser without its sandbox without being asked. [10][14]
Daemons are per session and stay alive between commands. Without a --session name every agent on the machine shares the same default session, and so the same browser, and the session settings live in owner-only files in the user's runtime directory. [13][12]
Telemetry
None documented We found no analytics or crash reporting in the CLI code. The one routine outbound request is an on-by-default check of Google's Chrome release feed.
The CLI source has no code that sends analytics or crash reports. A search for analytics, telemetry, PostHog and Sentry matches five files: the CDP protocol definition, actions.rs and the flow module, recorder and replay code, where the matches are names and a list of telemetry paths that the recorder skips. The hosts the code calls are Google (browser download and release feed), the npm registry (for the upgrade command), the cloud browser providers you select, and Vercel's AI Gateway for chat and the doctor network probes. [18][19]
The Chrome version check is on by default: when you drive Chrome it reads the version and compares it with Google's Stable Channel release blog, warning about unpatched CVEs, once per version per session. It never blocks a command. AGENT_BROWSER_NO_VERSION_CHECK=1 turns it off, and in our trace the extra connection to a Google address from the daemon appeared only without that variable. [12][14]
Chrome is launched with --disable-background-networking, yet in our trace Chrome still made its own requests to Google while showing a localhost page. The security doc tells you to combine the allowlist with host or network controls, so enforce a strict outbound policy at the firewall and not only with agent-browser's flags. [10][12]
Before you use it at work
Run agent-browser with a named session per agent (--session name) and never the shared default, and close it when the task ends so the daemon and its Chrome do not linger.
Set --allowed-domains for every task that needs a login or reads internal pages, and test it once: open a page you did not list and check that it is refused.
If you write an action policy, test each rule: run the action you meant to block and confirm it fails. In 0.42.0 the doc example for eval does nothing, and the working action name is evaluate.
Do not save state (state save) to a shared folder without AGENT_BROWSER_ENCRYPTION_KEY set. Prefer the auth vault, which always encrypts, over passing passwords in commands.
Set AGENT_BROWSER_NO_VERSION_CHECK=1 if your policy forbids unlisted outbound requests, and unset CI in developer shells so Chrome keeps its sandbox.
Use --content-boundaries so page text reaches the model wrapped and labeled as page content. It limits prompt injection, it does not remove it: in our test a page that said to ignore earlier instructions was returned to the agent as ordinary text.
Checked Read on 10 November 2026: the LICENSE file, README, security, sessions, streaming and configuration docs, and the installer, update, policy, Chrome launch and Chrome version check code. Run in a temporary sandbox on Ubuntu 24.04 with Node 22: npm install, browser download, a snapshot, fill and click loop, a hostile test page, the allowed-domains and policy switches, state save and the auth vault, with the system calls traced. Not checked: a real logged-in site, macOS and Windows, the cloud browser providers, the chat command, plugins, and whether other clients can talk to the local stream port beyond the one connection test.
Sources
Every statement above carries the numbers of the rows that back it. Why this project: On GitHub Trending (daily and weekly) on 9 November 2026. An agent that drives a real browser can reach logged-in sessions, so where its data goes matters to a team policy.