ego-lite: A Browser Where AI Agents Share Your Chrome Login Without Stealing Your Tabs
Recently I came across a project on GitHub: ego-lite, a browser for human-AI agent collaboration, built to solve the pain points of web automation for AI agents like Claude Code, Codex, and Cursor. It lets humans and agents share the same login session without fighting over tabs. I've been using it for a while and found it quite useful, so here's a share.
Just remember a few key facts about this project:
- Project:
ego-lite, an AI Agent browser from Citro Labs. Agents run web automation in isolated workspaces and directly reuse your real Chrome login state. - Tech stack: JavaScript, MIT license. Install gives you a desktop browser + an
ego-browsercommand-line tool. - Popularity: 18,373 stars, measured on the day this was written.
- Iteration: Repo opened in April this year; v2.1.0 released October 16; commits still happening on the day of writing.
- Platforms: macOS (Apple Silicon and Intel) and Windows installers available; Linux is on the roadmap.
- Business: Browser is free, no subscription. The team compared itself against tools like
playwright-clion 31 real website tasks and claims it's 47% to 63% faster. That kind of claim can't be verified, so take it with a grain of salt. - URL: github.com/citrolabs/ego-lite
What it does is simple enough to sum up in one sentence:
ego-lite is a Chromium browser shared by humans and AI Agents. Agents do browser work in their own independent Spaces, inheriting your login state, cookies, and extensions from Chrome, without fighting over tabs. It works out of the box, with no complex remote debugging protocol setup.

Core capabilities, one by one
1. Space isolation (the core design)
There's a built-in isolated Space area. Each browser task opens its own Space; your own browsing tabs stay in the main Space, while AI Agents run automation tasks in their dedicated Spaces. Multiple agents can run multiple web tasks in parallel without interfering with each other, without hijacking pages you're using, and without switching your windows. You can jump into an agent's Space at any time to watch progress, take over an operation, or handle CAPTCHAs and sliders that need manual verification.
2. Direct reuse of your login state and cookies
One-click import of all Chrome configuration: saved passwords, cookies, login sessions, extensions, and bookmarks. When an agent executes web operations, it inherits your logged-in state directly. No need to re-login from scratch, bypass CAPTCHAs, or deal with SSO every time. This is the biggest advantage over Playwright/Browser-Use.
3. Native agent invocation: the ego-browser skill
No need to write complex CDP or webdriver scripts. Agents use the /ego-browser command to assign tasks in natural language: filling forms, scraping pages, clicking, taking screenshots. Underneath is a native Chromium kernel snapshot, not a JS-injection shim, so it can reliably recognize Shadow DOM, cross-origin iframes, and third-party components that many traditional automation tools miss. It also batches page actions, reducing the number of LLM tool calls, saving tokens, and improving speed.
4. Data stays local
Browsing cookies, login info, and page content are all stored on your machine, not uploaded to the cloud. No account registration required; you just configure your own model API key.
5. Can also be used as a daily browser
The kernel is Chromium, so Chrome extensions, tab groups, incognito mode, and bookmarks all work. You can do everyday browsing and agent automation in the same browser, without running Chrome plus a headless browser as two separate environments.
The core difference between ego-lite and traditional Chrome
After reading the above, you might wonder: ego-lite seems like just a browser, so what makes it different from traditional Chrome? Don't worry, here's a table to make it clear.
| Comparison | Chrome (traditional browser) | ego-lite |
|---|---|---|
| Positioning | Built primarily for human browsing | Human-agent dual: daily browsing + AI Agent automation run together |
| Automation approach | No native agent adaptation. Automation requires Playwright/Puppeteer/Browser-Use, which spin up a fresh headless instance with no login cookies, or CDP remote debugging, which often steals tabs and causes conflicts | Native agent call entry point built in, with the ego-browser skill; no separate headless instance needed; reuses current browser config and login state |
| Task isolation | No built-in isolation; script automation easily pollutes tabs you're browsing; multiple automation tasks fight each other | Space mechanism isolates agent tasks; multiple parallel tasks don't interfere; human and agent browsing environments are separate |
| Element capture | Automation relies on JS selector injection; Shadow DOM and iframes often fail to recognize | Semantic snapshot at the kernel level reads the page DOM directly, better compatibility with complex frontend components |
| Usage cost | Automation requires lots of scripts, maintaining selectors, and handling login state | Agents assign web tasks via natural language, zero configuration, very low learning cost |
One extra line on the core difference: Chrome is for humans, automation is an add-on; ego-lite is designed from the ground up as a browser shared by humans and AI Agents.
Why testers need it
Web automation has been around for years; scripts themselves are not the hard part. The blocker is usually step one: login. Internal company systems are all SSO, redirecting through layers, plus SMS CAPTCHAs, QR codes, and risk-control sliders. Playwright's storageState can save login state, but server tokens invalidate on rotation, and test accounts get risk-control locked after a few days. A five-minute feature verification turns into two hours of maintaining the login environment.
So a lot of internal system verification still relies on manual clicking. Every morning, open a dozen backends, check service status, compare data, review configuration. The only thing standing between you and automation is login.

On the other side, some people now assign these jobs directly to AI Agents, hooking a playwright-mcp or chrome-devtools-mcp to Claude Code to drive the browser. Problems cluster in three places. The agent usually spins up a fresh blank instance with no login state, so you still have to handle login first. Every click is a tool call, and the context re-sends every round, burning tokens fast. Either it's headless and you can't see the process, or the agent shares your window and you have to stop when it moves.
ego-lite solves half of each of these two blockers. Login state is inherited, so the agent works with a real session; execution happens in a Space, visible and controllable.
ego-lite VS Playwright / Browser-Use (traditional automation frameworks)
Playwright and Browser-Use are essentially automation SDK libraries; they require code to call and spin up a separate headless browser process. ego-lite is a browser foundation with a runtime that agents can call natively.
- Playwright: Each launch creates a fresh clean browser context with no login state, easily triggering risk control and CAPTCHAs. It depends on CSS selectors; when frontend styles change, scripts break. It suits stable CI pipelines and standardized E2E regression.
- ego-lite: Reuses your real browser fingerprint and login state, suitable for exploratory testing, backend page verification, AI Agent web evaluation, and human-agent collaborative testing. No need to maintain many stable selectors; very low cost for complex login systems. It doesn't replace Playwright; it complements it.
One-line summary: Chrome is a browser for humans, automation is an add-on; Playwright is about writing scripts to drive a headless browser; ego-lite is a browser built specifically for an AI Agent to share with you.
Installation and quick start
Method 1: Directly download the app.
macOS has DMG files for Apple Silicon and Intel; Windows has an exe. The official site (https://lite.ego.app/) has them.

On first launch, it asks whether you want to migrate Chrome data. Click yes, finish onboarding, and the ego-browser command registers into PATH, typically at ~/.local/bin.
Method 2: Install only the skill.
npx skills add citrolabs/ego-lite
When you first run a browser task it will guide you to install the app.
Method 3: Let the Agent install it itself. Paste this directly into Claude Code and let it follow the README.
Set up ego lite for me: https://github.com/citrolabs/ego-lite
Read `skills/ego-browser/references/install.md` and follow the steps to install ego lite.
Verify once installed.
command -v ego-browser
ego-browser nodejs -e "console.log('ego-browser ready')"
If it prints ego-browser ready, it works. Windows has a documented pitfall: PATH changes only take effect in a new terminal.
Two details when connecting to Claude Code. Use Code mode; /ego-browser won't appear in Cowork mode. Permission-wise, enable bypass permissions: on desktop switch it in the permission selector next to the input box; in terminal launch with claude --dangerously-skip-permissions. The reason is simple: the agent has to be able to start browser processes itself.
Then you can assign tasks.
/ego-browser open the issues of github.com/anthropics/claude-code, compile the titles, tags, and reply counts of the last 10 into a table for me
The agent opens its own Space, writes the code itself, and organizes the results back. During the process you can click into the Space to watch it work; if a CAPTCHA appears, take over directly, then tell it to continue.
Or use this command to call ego-browser:
/ego-browser
Open our admin user management page, look up user id=1001, check if the user status is normal, save a screenshot of the page, extract the phone number and creation time. If you hit a CAPTCHA, stop and hand it over to me.
After execution, ego-lite automatically opens a separate Space, opens the page inside it, and runs the operation; it doesn't touch the tab you're currently browsing. When done, the agent returns the extracted results and screenshot. If a slider CAPTCHA appears mid-task, the task pauses automatically, notifies you to switch to that Space for manual verification, then continues.
You can also use it for form automation, page patrols, data export, and other web tasks.
From zero to working: download the app, migrate data, assign a task in one sentence. Three steps.
How the agent actually works inside
The whole flow is tied together by a skill. Once ego-lite is installed, the ego-browser skill goes into ~/.claude/skills, and it's also written to other agents' skill directories. When you type /ego-browser plus a task description in Claude Code, the agent reads the skill, runs ego-browser skill to get usage instructions, then gets to work.
The underlying layer looks like this: a heredoc handed to Node.js, with browser capabilities pre-injected as functions, no import needed.
ego-browser nodejs <<'EOF'
const task = await useOrCreateTaskSpace('search github issues')
await openOrReuseTab('https://github.com/issues', { wait: true, timeout: 20 })
cliLog(await snapshotText())
EOF
useOrCreateTaskSpace opens a task space, openOrReuseTab opens a page, snapshotText turns the page into structured text and prints it. The agent reads the snapshot, then writes the next step.
await click('@21', { label: 'check the login state' })
await fillInput('@2', '[email protected]')
Labels like @21 are only valid for the latest snapshot; once the page changes you need to re-snapshot. To reference across steps, use loc= selectors or write CSS directly.
When to choose ego-lite, when to use Playwright?
✅ Choose ego-lite:
- Doing AI Agent web interaction evaluation, Harness task verification
- Internal backends, enterprise SaaS with complex login, 2FA, risk-control checks
- Need human and agent to alternatingly take over a page, watch and adjust
- Don't want to spend lots of effort maintaining login scripts, account pools, complex selectors
✅ Keep using Playwright:
- Large-scale stable E2E regression in CI pipelines
- No login, public pages, standardized business flows
- Need containerized, clustered batch execution of test cases
Final words
Writing to the end, many people doing AI testing and agent evaluation hit the same wall: our agents can understand natural language, but it's hard for them to interact stably and cheaply with real web systems.
The cleverness of ego-lite isn't a new automation syntax. It's a different approach: instead of making the automation process an isolated, clean, headless instance that risk control easily blocks, let the agent be your collaborator, reusing your real, trusted browser session, doing tests, patrols, and page verification in an isolated space.
The tool is optional, depending on what your team is working on, but two perspectives strike me as more valuable than the tool itself.
Login state is a test asset. The session you use every day is fresher and more reliable than any test account or exported storageState. Even if you don't install ego-lite, it's worth thinking about how to let automation directly consume real login state; the hours saved from login maintenance are pure profit.
The execution model perspective also generalizes. Having an agent write a whole program and run it in one go, versus watching it step by step, costs several times less. When evaluating any agent tool later, first check which path it takes.
No need to force it, but learning these two new perspectives is worth more than installing another browser.
That said, it's worth mentioning that, like the Keploy, Promptfoo, DeepEval, and Langfuse we shared earlier, ego-lite is a valuable piece of the AI testing engineering chain. In our future enterprise-grade one-stop intelligent testing platform project, we plan to include ego-lite as an optional base for Web Agent evaluation, connecting agent task scheduling, page execution, result assertion, and report generation into a complete pipeline.
Project address is below, check it out if interested.
GitHub: github.com/citrolabs/ego-lite
Official site: lite.ego.app