Show HN: Drive your already-logged-in Chrome from any AI agent

forked from vercel-labs/agent-browser

Notifications You must be signed in to change notification settings

Fork 5

Star 46

BranchesTags

Open more actions menu

Folders and files

NameName

Last commit message

Last commit date

Latest commit

History

872 Commits

872 Commits

.claude-plugin

.claude-plugin

.github/workflows

.github/workflows

.husky

.husky

assets

assets

bin

bin

cli

cli

docker

docker

docs

docs

extensions

extensions

scripts

scripts

skill-data

skill-data

skills/chrome-use

skills/chrome-use

.gitignore

.gitignore

.node-version

.node-version

.nojekyll

.nojekyll

.prettierrc

.prettierrc

AGENTS.md

AGENTS.md

LICENSE

LICENSE

README.md

README.md

README.zh.md

README.zh.md

install.sh

install.sh

package.json

package.json

pnpm-lock.yaml

pnpm-lock.yaml

pnpm-workspace.yaml

pnpm-workspace.yaml

Repository files navigation

English · 简体中文

chrome-use drives your real, logged-in Chrome from any AI agent — it shares your existing login sessions and is undetectable by anti-bot systems because it is your real browser. Part of the *-use family (iphone-use drives your real iPhone; chrome-use drives your real Chrome).

Originally based on vercel-labs/agent-browser (Apache-2.0); now a standalone project — the stealth/extension-relay architecture, anti-detection, humanize, multi-agent isolation, and CLI have diverged substantially.

📖 Deep dive: Letting an agent click into cross-origin iframes — how chrome-use solves the hardest part of browser control

Give your AI agent the browser you already live in

No fresh Chrome. No re-login. No "are you a robot?" walls.

chrome-use points any agent — Claude Code, Cursor, Codex, your own scripts — at the Chrome you're already signed into everything on. It clicks in your window, so you watch it work and grab the wheel the moment it hits a 2FA prompt or captcha. And because it's literally your real browser (over a one-click extension, native messaging — no debug port), sites read it as 100% human: CreepJS scores it 0% bot.

Why not just use…

Playwright / Puppeteer / browser-use? They boot an empty browser — so you redo every login, fight every captcha, and still get flagged as automation. We use the session you already have.

Claude's Chrome extension? Great, but it only drives Claude. This drives any agent or CLI.

A raw --remote-debugging-port (web-access, etc.)? Chrome 136+ pops "Allow remote debugging?" on every connect. This never does — one-click Store extension, native messaging.

Full feature comparison (the receipts)

Claude in Chrome web-access / raw CDP port Playwright · Puppeteer · browser-use chrome-use

Works with any agent / CLI (not one app) ❌ Claude only ✅ ✅ ✅

Drives your real, logged-in Chrome ✅ ✅ ❌ fresh empty profile ✅

No "Allow remote debugging?" popup ✅ ❌ every connect — (own browser) ✅ native messaging

Real-browser fingerprint (CreepJS ~0%)¹ ✅ ✅ ❌ automation markers / headless ✅ verified 0%

No Runtime.enable CDP leak (rebrowser)² — ❌ leaks ❌ leaks ✅ off by default

Many agents on one real Chrome, isolated tab groups³ ❌ single app ⚠️ shared tabs, no isolation ❌ separate browsers ✅

Permissions footprint 16 incl. full CDP full control 7, no

¹ All three real-Chrome tools score ~0% on CreepJS (it's a real browser); we've measured ours. ² rebrowser's runtimeEnableLeak — verified clean on our relay path; Claude in Chrome not independently tested (—). ³ web-access can run parallel sub-agents on one browser, but without per-session isolation; each --session here gets its own colored, command-isolated tab group. See Anti-detection for the measured numbers.

Why chrome-use?

Typical browser automation (Playwright, Puppeteer, or a fresh --launch) opens a brand-new browser with an empty profile. You have to log in again, and websites can tell it's automated.

chrome-use connects to your existing Chrome. Your cookies, sessions, and browser fingerprint are all real — because it IS your real browser.

chrome-use chrome-use

Browser Launches new Chrome Connects to your Chrome

Login state Empty, need to re-login Your existing sessions

Fingerprint Automation markers present Your real fingerprint

User collaboration Separate window Same window, take over anytime

CAPTCHA Agent stuck You solve it, agent continues

How it works

Your chrome-use CLI talks to a tiny browser extension over Chrome native messaging — a local inter-process channel, no network socket, no token, no remote server. The extension uses chrome.debugger to drive the tabs you target in your own, already-logged-in Chrome, then hands results back to the CLI. Everything stays on your machine.

Each --session gets its own colored Chrome tab group, so multiple agents can share one real browser concurrently without stepping on each other — or your own tabs.

Why the extension (not a raw debug port)

Other local tools drive Chrome over a raw --remote-debugging-port (CDP). Since Chrome 136, every such connection pops a blocking "Allow remote debugging?" consent dialog — and the port has to be enabled up front. Our extension uses native messaging instead: install once, then zero per-use confirmation.

chrome-use (this extension) web-access (raw CDP port) Claude in Chrome (chrome.debugger)

Connect method native messaging — no port, no token --remote-debugging-port chrome.debugger

"Allow remote debugging?" popup never ✅ every connection 🔴 no

Uses your real login yes yes yes

Runtime.enable (CDP) leak¹ off by default → clean ✅ domain enabled n/a

CreepJS stealth score² 0% stealth · 0% headless ✅ real Chrome real Chrome

Per-session tab groups / concurrent agents yes ✅ no no

Built for the chrome-use CLI yes a separate proxy a single-app assistant

¹ Verified against rebrowser-bot-detector: our relay reports runtimeEnableLeak: 🟢 No leak and navigatorWebdriver: 🟢. ² Verified against CreepJS on the connected real-Chrome path — see Anti-detection.

The consent dialog isn't hypothetical: a raw-port tool pops it on every attach (Chrome 136+ security). The extension path never does.

Install

curl -fsSL https://raw.githubusercontent.com/leeguooooo/chrome-use/main/install.sh | sh

Downloads the prebuilt binary for your platform from the latest GitHub Release and installs chrome-use (+ the abs alias). No npm, no tokens.

Other ways to install

Pin a version: AGENT_BROWSER_VERSION=v0.27.0-fork.12 curl -fsSL https://raw.githubusercontent.com/leeguooooo/chrome-use/main/install.sh | sh

Custom location: AGENT_BROWSER_BIN_DIR=$HOME/bin curl -fsSL … | sh

Windows: download chrome-use-win32-x64.tar.gz from the Releases page and put chrome-use.exe on your PATH.

npm (legacy): npm install -g chrome-use — still published, but GitHub Releases is the primary channel now.

Install the AI agent skills

The repo ships SKILL.md files for Claude Code, Cursor, etc. Pull them into the current project with skills.sh:

npx skills add leeguooooo/chrome-use

This drops skills/chrome-use (and the specialized skill-data/{core,electron,slack,dogfood,agentcore,vercel-sandbox}) into your project so your AI agent gets the right usage patterns and pre-approved bash permissions for chrome-use, chrome-use, and abs.

Command names

chrome-use, chrome-use, and abs are the same binary — abs is just a short alias. There is no separate "stealth executable"; stealth is a runtime behavior (see Anti-detection below), applied automatically based on whether you attach to your real Chrome or --launch a fresh one.

Setup: connect to your Chrome

Recommended — the browser extension (one click, no popups). Install the chrome-use extension from the Chrome Web Store, then register the local bridge once:

chrome-use extension install # register the native-messaging host (one-time) chrome-use open https://x.com/home

chrome-use open then drives your real, logged-in Chrome over native messaging — no debug port, no token, and no "Allow remote debugging?" dialog, ever. The extension auto-updates and survives Chrome restarts, so it stays connected with zero per-use confirmation (ideal for unattended/agent use).

Alternative — raw remote-debugging port (pops a consent dialog)

Without the extension, chrome-use attaches over the Chrome DevTools Protocol, which Chrome only exposes when launched with a remote-debugging port (a startup flag — the chrome://inspect toggle alone is not enough):

macOS

open -a "Google Chrome" --args --remote-debugging-port=9222

Linux

google-chrome --remote-debugging-port=9222

Windows: add --remote-debugging-port=9222 to your Chrome shortcut's target

Then chrome-use open auto-discovers the port. On first attach, Chrome 136+ shows an "Allow remote debugging?" dialog — click Allow once (it persists for that Chrome session). The extension above avoids this entirely.

No setup / don't want to touch your real Chrome? Use chrome-use --launch open to spawn a fresh isolated stealth browser (full anti-detection patches applied; see below). This always works without any port setup and is what CI uses automatically.

Usage

Connect to your Chrome and navigate

chrome-use open https://example.com

Everything works through your logged-in browser

chrome-use click "Post" chrome-use click 449 320 # …or click a raw viewport coordinate chrome-use fill "Title" "Hello World" chrome-use screenshot ./page.png

The agent operates in your Chrome — you'll see tabs opening, pages loading, clicks happening in real time. You can take over at any point (e.g. solve a CAPTCHA), then let the agent continue.

Standalone mode (--launch)

Spawn a separate browser instead of attaching to your running Chrome:

Throwaway: fresh, EMPTY profile — no cookies, no login (good for CI/testing)

chrome-use --launch open https://example.com

Keep your login: launch with your real Chrome profile (cookies/sessions intact)

chrome-use --launch --profile auto open https://x.com/home

or name it explicitly: --profile Default / --profile "Profile 1"

⚠️ Plain --launch (no --profile) uses a temporary empty profile — you will NOT be logged into anything. For logged-in sites use --profile auto (picks the Chrome profile you used most recently) or --profile . chrome-use prints a warning when you --launch without a profile.

In CI environments, standalone mode is used automatically.

Site adapters — turn a website into a structured-data CLI

Most "read GitHub issues" / "search Reddit" / "get my Bilibili feed" tasks don't need clicking and screenshotting at all — the site already has a JSON API behind its own login. A site adapter is a tiny JS function that calls that API from inside your logged-in tab (your cookies, same-origin fetch, the site's own modules) and returns clean JSON. The site can't tell it apart from you, because it is you.

chrome-use ships none of these adapters — site update fetches the community bb-sites pack at runtime (like a package manager pulling a dependency), then runs them over chrome-use's stealth transport:

chrome-use site update # fetch the adapter pack (~145 commands) chrome-use site list # github/issues, reddit/search, bilibili/feed, … chrome-use site info github/issues # see an adapter's args + domain

Run one — navigates to the site (reusing the tab if you're already there) and returns JSON

chrome-use site github/issues epiral/bb-browser --json chrome-use site reddit/search "rust async" --json chrome-use site bilibili/feed --json # works because it's your logged-in session

Positional args fill the adapter's declared args in order; --key value overrides by name. Adapters are authored by the bb-sites community and remain their authors' property — chrome-use just runs them.

Auto-sync + auto-suggest. You rarely type site update yourself: chrome-use syncs the pack on first use and refreshes it weekly in the background (tune with AGENT_BROWSER_SITES_TTL_DAYS, disable with AGENT_BROWSER_SIT

[truncated for AI cost control]