Get This Tool
chrome-use
Pricing
- Model
- Free
Summary
Most browser automation breaks the moment a site asks for a CAPTCHA, throws up a 2FA prompt, or detects that the browser fingerprint doesn't match a real user — at which point your agent is dead in the water. chrome-use sidesteps that wall by driving your actual installed Chrome, with your real sessions already logged in.
Because chrome-use attaches to the Chrome instance you already use day-to-day, the agent inherits your cookies, your fingerprint, and your authenticated state — no credential injection, no headless flags that anti-bot systems fingerprint in milliseconds. The extension-relay architecture means the browser looks identical to your normal traffic. Where it breaks: tasks that need a clean isolated session per run, or parallel agents that must operate on separate authenticated identities simultaneously, get complicated fast because you are sharing one browser. Teams hitting that ceiling wire in additional Chrome profiles or move the workflow to a cloud browser infrastructure that supports session isolation at scale.
Bottom line: Pick this when an agent needs to act inside your personal accounts on sites that would block anything headless — and plan a different approach when you need parallel isolated sessions that do not share your personal login state.
Community Performance Report Card
No community ratings yet. Be the first to rate this tool!
Community Benchmarks Community
Sign in to submit a benchmarkNo community benchmarks yet. Be the first to share a real-world data point.
Pros
Sign in to edit- Drives your actual installed Chrome with real session cookies already present, so agents can act inside accounts on sites that would immediately block a fresh headless session.
- Anti-bot detection passes by default because the browser fingerprint, TLS signature, and extension profile are all genuine — teams do not need to maintain rotating proxies or fingerprint spoofing layers to get past these checks.
- CAPTCHA and 2FA prompts pause the agent loop and let you intervene directly in your open browser, then hand control back — so workflows don't hard-fail on authentication challenges the way headless runners do.
- Apache-2.0 license with a self-hosted CLI means no vendor lock-in, no usage metering, and no data leaving your machine during automation runs.
- Multi-agent workflows can share one authenticated browser instance without re-authenticating per agent, which removes the credential management complexity that burns time in multi-step pipelines.
Cons
Sign in to edit- Parallel automation against multiple accounts hits a hard wall: because the tool shares your single Chrome instance and its session state, running two agents on two different logins at the same time requires maintaining separate Chrome profiles and coordinating which profile each agent targets — at which point session management becomes a manual orchestration problem your team now owns.
- Unattended server-side automation is not a supported model — the tool requires a running Chrome instance on the host machine, which means it does not fit into a headless CI/CD pipeline or a cloud worker that spins up on demand. Teams that need fully unattended, server-side browser automation switch to Playwright-based runners or cloud browser providers like Browserbase or Steel.
- There is no API surface — agents integrate exclusively through the CLI or extension relay, so dropping chrome-use into an existing platform that expects a REST or WebSocket browser control interface requires building a wrapper layer your team then maintains across version updates.
Community Reviews
Sign in to write a reviewNo reviews yet. Be the first to share your experience.
About
- Platforms
- Chrome (via extension), cross-platform CLI
- API Available
- No
- Self-Hosted
- Yes
- Last Updated
- 2026-06-25T07:40:27.408Z
Best For
Who it's for
- Developers building agentic browser tools
- Users who need agents to act inside their personal accounts
- Scenarios requiring real-browser fingerprints and session continuity
What it does well
- AI agents performing web tasks while using existing user sessions
- Automated browsing with CAPTCHA or 2FA intervention by the human operator
- Multi-agent workflows sharing one authenticated browser instance
- Stealth web automation undetectable by common bot-detection systems
Integrations
Discussion Community
Sign in to commentNo discussion yet. Sign in to start the conversation.
Compare chrome-use
Spotted incorrect or missing data? Join our community of contributors.
Sign Up to ContributeCommunity Notes & Tips Community
Sign in to contributeBe the first to contribute. General notes, observations, gotchas, and tips from people who use this tool day-to-day.
Frequently Asked Questions
- Is chrome-use free?
- Yes — chrome-use is fully free to use. There is no paid tier.
- Is chrome-use open source?
- Yes. chrome-use is open source.
- Can I self-host chrome-use?
- Yes. chrome-use supports self-hosting on your own infrastructure.
- What platforms does chrome-use support?
- chrome-use is available on: Chrome (via extension), cross-platform CLI.
Hours Saved & ROI Stories Community
Sign in to contributeBe the first to contribute. Concrete time/cost savings, with context. e.g. "Cut my code review backlog from 4h to 45m per week."
Best chrome-use alternatives →
Curated lists that include this category
Browser automation built for sites that reject bots starts by asking the wrong question — how to disguise a headless browser — when the right answer is to stop using a headless browser. chrome-use drives your real, already-running Chrome via a CLI, relaying instructions from any AI agent through an extension that sits inside the browser itself. The agent sees the page, takes actions, and the site sees a normal user. The core workflow: start the CLI, point your agent at it, and it drives whatever Chrome tabs you have open, using whatever sessions are already authenticated.
The differentiating architecture here is the extension-relay design, forked and extended from vercel-labs/agent-browser (Apache-2.0). Instead of launching a separate controlled browser that sites can fingerprint, the extension bridges your agent’s instructions into the real browser process. That means every request carries your actual TLS fingerprint, your real browser extensions, your genuine cookie jar — the signals anti-bot systems look for are all correct because they are all real.
This fits tightest in personal-automation scenarios: an agent that needs to log into your bank, file a form inside a work portal you’re already authenticated to, or navigate a site that blocks anything that looks like automation. It also covers multi-agent workflows where several agents share one authenticated browser instance, passing control between tasks. Where it does not fit: any scenario requiring multiple isolated sessions running in parallel on different accounts, or fully unattended server-side automation where no human Chrome instance is running. Those use cases require a different architecture — cloud browser providers that spin up isolated sessions on demand.
chrome-use is Apache-2.0 licensed, self-hosted, and CLI-driven with no API surface of its own — agents integrate by invoking the CLI or through the extension relay. Docker support is included in the repository for containerized setups. The project is part of a broader *-use family (the vendor states iphone-use drives a real iPhone with the same philosophy), and the GitHub repository includes skill data, a Claude plugin directory, and documented extension structure for contributors building on top of it.