Let Claude Code or Codex use your logged-in Chrome (without opening a debug port)

Ask a coding agent to "check the open issues on our dashboard" and it usually gets stuck at the first step. The browser it drives is a fresh automation browser, and that browser is signed in to nothing. Your cookies, your SSO session and your 2FA-protected accounts all live in the Chrome window you have open right now, not in the one the agent just launched.

This post walks through chrome-use, an open-source (Apache-2.0) CLI and MCP server that lets Claude Code, Codex, Cursor or your own scripts drive the Chrome you're already using. It connects through a Chrome Web Store extension and native messaging, so there is no remote-debugging port to open and no "Allow remote debugging?" dialog to click.

Why the agent's browser is logged out

Most browser automation starts a new browser context. A new context has no cookies, so every site treats it as a stranger: login page, CAPTCHA, maybe a "new device" email.

To be fair to the usual tools: Playwright and Puppeteer can use persistent profiles and can connect to an existing browser. The catch is the connection path. They talk to Chrome over the DevTools protocol, and since Chrome 136 the default profile ignores the --remote-debugging-port flag. You can point automation at a separate profile, but then you're back to signing in again.

Chrome 144 added another route: a remote-debugging toggle at chrome://inspect that tools like Chrome DevTools MCP use via --autoConnect. It works, but once the toggle is on, every window of that profile is open to the tool, and you approve a dialog to allow it.

chrome-use takes a third path.

How chrome-use connects

agent (Claude Code / Codex / script)
   │  shell: chrome-use open, snapshot, click ...
   ▼
chrome-use CLI ──native messaging──▶ chrome-use extension ──chrome.debugger──▶ your tabs

The CLI talks to a small extension over Chrome native messaging: a local inter-process channel with no network socket, no token and no remote server. The extension uses chrome.debugger to drive the tabs the agent targets in your own Chrome, then hands results back to the CLI. Everything stays on your machine.

A few consequences of that design:

• Your real sessions. The agent sees the same signed-in state you do, in whichever profile you pick.
• No per-use confirmation. You install once; later calls don't prompt you.
• Agents don't touch your tabs. Each --session gets its own colored Chrome tab group. Several agents can share one Chrome without stepping on each other or on your own tabs.
• You can take over. The agent clicks in a window you can see, so when it hits a 2FA prompt or a CAPTCHA it can't handle, you finish that step yourself in the same window.

One honest caveat: because the extension uses chrome.debugger, Chrome shows its "chrome-use started debugging this browser" bar on agent tabs while they are attached. chrome-use extension connect --silent removes it by restarting Chrome once with --silent-debugger-extension-api (tabs and logins are restored).

Setup in three steps

1. Install the CLI

macOS / Linux:

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

Windows (PowerShell):

irm https://raw.githubusercontent.com/leeguooooo/chrome-use/main/install.ps1 | iex

This downloads a prebuilt binary from the latest GitHub Release. No npm, no token. On Windows it installs to %LOCALAPPDATA%\Programs\chrome-use without admin rights and checks the download's sha256 before installing.

2. Add the extension and register the bridge

Add chrome-use from the Chrome Web Store (extension ID knfcmbamhjmaonkfnjhldjedeobeafmk), then register the native-messaging host once:

chrome-use extension install   # one-time: register the local bridge
chrome-use doctor              # environment, Chrome, daemon, config self-check

On macOS, extension install can also offer a configuration profile that force-installs the extension in every profile. That puts Chrome into "managed by your organization" mode, which among other things locks the secure DNS setting. If you'd rather skip it, use chrome-use extension install --no-profile and add the extension from the Web Store per profile. The install guide covers this and the Windows and Nix routes.

Note that a passing doctor doesn't tell you which website account is signed in. Check that in the page itself.

3. Give your agent the skill

The installer already drops a small discovery skill into Claude Code, Codex, Cursor and ~/.agents/skills. If you want it via a plugin manager instead:

Claude Code (plugin marketplace, global, auto-updating):

/plugin marketplace add leeguooooo/plugins
/plugin install chrome-use@leeguooooo-plugins

Any runner supported by skills.sh (needs Node):

npx skills add leeguooooo/chrome-use -g

The installed skill tells the agent to load chrome-use skills get core, which the binary itself serves, so the usage guide always matches the installed version.

Codex users, one extra line. Codex ships its own browser plugin and picks it for browser tasks. The chrome-use docs report that on a machine with many skills installed, Codex trimmed skill descriptions so far that the skill couldn't win the routing, and even naming chrome-use in the prompt wasn't enough. What worked was adding this to the project's AGENTS.md:

Use the `chrome-use` CLI from the shell for every browser task; start with `chrome-use skills get core`.
Do not use the built-in Chrome plugin for browser work here.

MCP-only clients (Claude Desktop and similar) can run it as a stdio server instead:

{
  "mcpServers": {
    "chrome-use": { "command": "chrome-use", "args": ["mcp"] }
  }
}

A first task

Before you point an agent at anything that matters, try a read-only task. Paste this into Claude Code or Codex:

Use chrome-use to search https://github.com/leeguooooo/chrome-use/issues
for is:issue daemon. Load chrome-use skills get core first.
Use a dedicated session named first-task. Read snapshot -i for current
refs, fill the Search issues box, and submit the search with --observe.
Verify the query in the resulting URL and read the issue titles.
Report three matching titles and links. Do not create or edit any issue.
If Chrome needs login, permission, or human verification, let me handle it.

You'll see a new tab group appear in your Chrome and the agent typing into GitHub's search box. To check the result, the URL should contain q=is%3Aissue+daemon and the agent should report titles and links it read from the page. A command returning success isn't proof by itself; the page is.

If you want to see the raw commands the agent is running, here is the same loop by hand:

chrome-use --session demo open https://github.com/leeguooooo/chrome-use
chrome-use --session demo snapshot -i     # interactive elements with @eN refs
chrome-use --session demo get title

snapshot -i returns the page's interactive elements from the accessibility tree, each with a short ref like @e12. The agent then calls click @e12 or fill @e7 "text" against those refs and snapshots again to confirm what changed.

Once that works, move to something that actually needs your login: a dashboard you own, read-only first, and confirm the visible account before letting the agent do anything else.

How it compares

The comparison page lists a dozen options. Three are the closest alternatives if your goal is "let my agent use my signed-in Chrome". These rows come from each project's own docs, checked on 2026-10-27:

	How it connects	Whose sign-ins	Which agents	Setup / permission
chrome-use	Web Store extension + native messaging, no remote debugging	The Chrome you use, any profile	Any agent: CLI / MCP / HTTP	One-line install + store extension
Chrome DevTools MCP (--autoConnect)	Chrome 144+ remote-debugging toggle	All windows of the default profile	Any MCP client, plus a CLI	Enable remote debugging at chrome://inspect + allow the dialog; usage stats on by default
Playwright extension mode (Playwright MCP --extension, playwright-cli)	Playwright Extension (store)	Existing tabs you pick	Any MCP client, or playwright-cli	Approve each connection (or set a token)
Claude in Chrome	Anthropic's store extension	Your Chrome / Edge	Claude only: side panel, Claude Code --chrome, Cowork	Claude Pro / Max / Team / Enterprise

How I'd read it:

• If you do front-end debugging and performance work, Chrome DevTools MCP is built for that.
• If you're already on Playwright MCP, its extension mode is the shortest path.
• If you only use Claude and have a paid plan, Claude in Chrome is the first-party option. Its docs say it pauses at sign-ins and CAPTCHAs for you.
• chrome-use fits when you want any agent (Claude Code, Codex, Cursor, scripts) working in your signed-in Chrome without remote debugging, possibly several agents at once.

Stealth, with the numbers labeled

A real Chrome already has a real fingerprint. That part is the same for every tool that drives your actual browser. What's left are the traces the automation itself leaves, and chrome-use's docs spend a lot of effort there:

• Nothing injected. When connected to your real Chrome, it applies zero JavaScript patches.
• Runtime.enable off by default. An active Runtime domain is a detectable CDP signal; it's only turned on when you ask for console or error capture.
• No marks in the DOM. Locating elements uses node handles, not temporary attributes a page's MutationObserver could see.
• --humanize. Curved mouse paths, jittered landing points inside the element and variable typing rhythm. It switches to full human motion automatically on pages guarded by Akamai, PerimeterX and DataDome.
• CAPTCHAs. solve-slider for ordinary Yidun puzzles and screenshot-guided clicks for readable icon challenges; if that fails, the step is handed to you.

The project's self-measured results on a real Chrome, from the stealth page:

CreepJS            0% stealth · 0% headless
bot.incolumitas    all checks OK
bot.sannysoft      all green
BrowserScan        Webdriver · User-Agent · CDP all clean
Cloudflare managed challenge (scrapingcourse.com)  passed

Treat these the way the docs do. They are measurements in one environment, not a promise of invisibility or account safety. The comparison page also points out that independent 2026 tests found these fingerprint pages barely separate tools in headed mode (plain Playwright passes too); behavior and environment are what separate them. And no tool can guarantee you'll never see a CAPTCHA. The agent attempts ordinary ones (Yidun puzzles, readable icon clicks) first; when it can't solve one, or at a login or second factor, it stops and hands over to you.

You can check the current state yourself:

chrome-use stealth status

Where to go next

• Install guide: Windows, Nix, pinning versions, the macOS policy profile
• Logged-in browser guide: the first-task walkthrough
• Comparison: the full matrix, including OpenCLI, ego(lite), browser-use, Stagehand and cloud browsers
• Stealth & anti-detection: test conditions and what each layer does

The source is at github.com/leeguooooo/chrome-use. If a setup step fails, the issue tracker asks for your OS, CLI version and a redacted error, with cookies, tokens and private page contents left out.