The core conclusion first: whether the agent moves into your browser or gets its own decides who owns your window during every task it ever runs. Vendor extensions (Claude for Chrome, Codex for Chrome, Browser MCP) put the agent in the browser you're using; a shared agent browser gives it its own window with your logins. For daily and parallel work, the shared-browser architecture wins.
Every vendor demo of a browser agent shows the same magic moment: the agent, in your browser, doing your task in your accounts. What the demo never shows is you, during those ninety seconds, doing nothing.
This article names the two architectures, walks one task through each, and shows the five places the difference bites in a normal week. By the end, "which browser agent should I use" should feel like the second question, downstream of the architectural one.
What are the two architectures?
The vendor extension architecture installs the agent into your daily browser. Claude for Chrome and Codex for Chrome are the flagship implementations, Browser MCP the protocol-flavored one; all three act on your real tabs with your real sessions, guarded by permission prompts.
Its genuine strengths: nothing to configure, sessions already present, and the agent sees exactly what you see. Its structural property: the browser executing agent tasks is the one you're trying to use, and no setting changes that.
The shared agent browser architecture gives the agent a separate browser that carries your logged-in state without being your window. ego (lite) is itself the browser, so there is no relay to install, pair, or keep connected; the agent then works in a Space, an isolated workspace with its own tabs, so a hundred parallel tasks can run while your own window stays exactly as you left it.
Its structural property: an extra browser exists, and your own never gets borrowed.
Note what's not the difference: login access. Both architectures solve that. The difference is purely who owns the window while the work happens.
"Any agent that can run a shell command" shouldn't be taken on faith either. Here's a recorded ego-browser session: a shell heredoc opening a task space, driving the page, and handing back exactly the four fields asked for, not a window, not a tab, not your attention.
ego-browser nodejs <<'EOF'
const task = await egoBrowser.newTaskSpace('evidence-egobrowser-hn')
console.log({ taskSpaceId: task.id })
await task.page.goto('https://news.ycombinator.com/', { waitUntil: 'load', timeout: 20000 })
const title = await task.page.title()
const topStory = await task.page.locator('.athing .titleline > a').first().innerText()
const points = await task.page.locator('.subtext .score').first().innerText().catch(() => null)
console.log({ title, url: task.page.url(), topStory, points })
EOF{
"taskSpaceId": 13
}
{
"title": "Hacker News",
"url": "https://news.ycombinator.com/",
"topStory": "Qwen 3.8 27B",
"points": "412 points"
}The same architecture has been measured, not just demonstrated: on Real-World Bench, a public 31-task suite run against live sites with the same model and judge across five tools, ego (lite) took the top spot on all six metrics, with 93.5% of 31 tasks finished perfectly. The suite runs errands of exactly this article's shape, work that sits in a Space while your window stays open: carrying Bankrate compound-interest results into an online spreadsheet, or pricing out a Houzz mood board's pieces at Home Depot.
A hybrid exists and clarifies the spectrum: DevTools-style auto-connect attaches an external agent to your live Chrome. It behaves like architecture 1 for our purposes (your window, occupied) while installing like architecture 2, which is why debugging guides love it and daily-task guides don't. The window question, not the install mechanism, is the load-bearing one.
What happens to your browser during one task, each way?
Take one ordinary task: "pull this month's invoices from our three vendor portals into a summary."
Extension architecture, from your chair: the agent opens the first portal in your browser; your tabs shift; you watch it navigate, or switch to another app and lose sight of what it's approving; a permission prompt lands mid-task and waits for you; nine minutes later your browser is yours again, with a few new tabs to close. The task succeeded. You were also, functionally, its supervisor for nine minutes.
Shared-browser architecture, same task: the agent opens a Space in its own browser, walks the three portals with your inherited sessions, and your browser never moves; you keep reading, writing, or browsing. If the task needs you (a 2FA challenge), it hands that one page over and takes back when you're done. Nine minutes later a summary arrives. Your window's role in the story: none.
Same task, same sessions, one hostage situation fewer. Multiply by every task you'll ever delegate, and the architectures stop looking interchangeable.
Where do the daily collisions happen?
Five recurring moments where architecture 1 charges its rent. Score your own week against them; two or more hits means the architecture, not any particular product, is your bottleneck.
The mid-email hijack: you're writing in one tab while the agent navigates in another, and a focus steal or tab switch drops your cursor mid-sentence.
The two-task queue: you want the agent checking prices while also filing a form, but one browser means one task; the second waits. The watching tax: because it's acting in your real profile, you feel obliged to watch, converting delegation back into supervision.
The interrupted handback: you grab your browser for something urgent mid-task, and the agent's run breaks or pauses; resuming costs more than the task saved. And the end-of-day tab archaeology: agent-opened tabs mixed into your own, in whatever state the last task left them.
None of these is a bug, and vendors mitigate at the margins (tab groups bundle the mess; permission prompts formalize the watching). The architecture guarantees the category; mitigation only shrinks instances. The tell is what users request: BrowserOS's community publicly asked for a "detached mode for assistant", agent working while the human keeps browsing, which is users of architecture 1 asking for architecture 2 by name.
How should enterprises govern agents and extensions?
Enterprise governance starts with an inventory of approved agents, browser extensions, data scopes, and owners—not with a blanket allow or block rule. Require an installation source, version tracking, least-privilege site permissions, a documented business purpose, and a way to revoke access. Security and IT teams should review extension changes and keep an audit trail of which agent acted in which environment.
A shared browser can make the boundary easier to see because agent work happens in a named Space rather than inside an employee's active window. That is a workflow boundary, not a compliance product: pair it with identity controls, endpoint management, DLP, logging, retention rules, and human approval for sensitive actions.
What can an agent see, and how do you limit access?
An agent can see the pages, text, controls, and session state exposed by the browser context you connect; it cannot see what that context cannot access. Treat every extension or shared-browser session as a granted capability: use a dedicated profile or Space, allow only the sites and accounts needed, remove access after the task, and review screenshots or logs for secrets before sharing them.
Never paste passwords, recovery codes, private keys, or one-time tokens into a prompt. Keep MFA, payments, account recovery, deletion, and messages behind a human handoff. If a tool requests broader permissions than the task needs, stop and choose a narrower context; a permission prompt is a decision point, not an obstacle to bypass.
How do you isolate multiple accounts and sessions?
Give each account, tenant, or client a separately named browser profile or Space, and verify the active identity before every consequential step. Do not rely on a tab title alone: check the visible account name, organization, and destination URL, and close or reset the context when the task ends.
Extensions running in one daily profile make cross-contamination easy when tabs, cookies, or autofill overlap. Separate Spaces reduce accidental mixing and let independent tasks run in parallel, but they do not replace your application's authorization checks or a careful identity confirmation before sending, purchasing, or changing data.
What data risks come with browser extensions?
A browser extension with broad host permissions may read page content, form fields, or messages on every permitted site. That does not prove a particular vendor sells data, but it does mean you should evaluate the publisher, privacy policy, requested permissions, update history, and data-retention terms before installing it. A tool that can read ChatGPT conversations or work email should be treated as access to sensitive business data.
Reduce exposure with least-privilege permissions, separate work and personal profiles, approved extension allowlists, and regular permission reviews. A separate agent browser limits window collisions, but you still need to understand what is imported into its session and where traces, screenshots, and prompts are stored.
How portable is agent context across platforms?
Portable context comes from explicit artifacts, not an agent silently remembering everything. Keep a short task brief, the source URLs, decisions, credentials policy, and the last verified result in a project-controlled document or ticket. Pass only the relevant excerpt to the next agent or platform, and label assumptions so a stale session is not mistaken for current truth.
A shared browser preserves useful login state within its imported context, while the ego-browser skill gives shell-capable agents a consistent way to open a Space. That is continuity of browser state, not universal memory: context still expires, permissions differ, and sensitive data should never be copied into an unapproved platform.
What happens when a session expires?
Session expiry should produce a clear pause and re-authentication handoff, not a guessed success. Design automations to detect redirects, sign-in prompts, and missing account identity; save the current URL and failure evidence; then ask an authorized person to refresh the session. After re-authentication, rerun the original assertion from a known checkpoint.
Extension scripts are especially sensitive to browser restarts, native-host disconnects, and expired cookies because they depend on the one profile you are using. Separate Spaces make the failure easier to contain, but no architecture can make an expired session valid or safely automate MFA without your approval.
Which agent interaction mode fits the task?
Use live-tab watching when you need to supervise a sensitive action in the exact page you already have open. Use a separate input channel or agent window when you want to keep typing and browsing while the task runs. Use a dedicated Space for repeatable, parallel work that should leave your tabs, focus, and history unchanged.
The right mode follows the risk and interruption cost: extensions optimize zero setup and immediate visual supervision; a shared browser optimizes delegation and isolation. Whichever mode you choose, make the stop conditions explicit and keep a human in the loop for actions that can send, purchase, delete, publish, or change access.
How do you decide, concretely?
Four questions, honest answers on both sides. How often do agent browser tasks run: a few times weekly favors the extension (its zero setup amortizes poorly-used installs), daily favors the shared browser (collision costs compound).
Do tasks run while you work, or instead of you working: parallel means architecture 2, sequential supervision means either. Is more than one agent or task ever active: extensions serialize on your one browser; Spaces parallelize.
And who are you setting this up for: a non-technical user gets real value from the extension's install-and-go, while anyone running a coding agent already has the shell the shared browser needs.
And the disclosure that colors this piece, stated plainly: we build ego (lite), the shared-browser side of this argument. The argument stands on the scenarios; check them against your own week rather than taking our word. If your week contains none of the five collisions, the extensions are genuinely fine, and this article was a taxonomy rather than a pitch. Where ego (lite) earns its place is the week that does, when the work happens while your own window stays yours.
Download ego (lite) for Mac, free, or compare it against the flagship extensions: Claude for Chrome and Codex for Chrome.
FAQ
Is the Claude Chrome plugin the same as Claude for Chrome?
Yes; "plugin," "extension," and "Claude in Chrome" all name Anthropic's browser extension, installed from the Chrome Web Store on paid plans. It's the flagship of the vendor-extension architecture this article describes.
The extension says site-level permissions are disabled for this site. What now?
That message means the site is excluded from agent actions under your current permission settings: some categories are restricted by the vendor's policy (sensitive and financial sites), others by your own site-level choices.
Review the extension's permission settings for that site; if it's policy-restricted, that's the guardrail working as designed, and the task belongs on a surface you supervise directly. What it isn't: a bug to work around, or a reason to grant allow-all.
My extension disconnected from the app. Quick fixes?
Extension-to-app pairings (both vendors use a desktop-app bridge) recover with the boring sequence: confirm the desktop app is running and current, restart the browser so the native-host connection re-establishes, and re-approve the pairing prompt if one appears. Persistent failures usually trace to the app having updated while the browser stayed open.
Is a shared agent browser the same as a multi-profile or antidetect browser?
No; different goals entirely. Multi-profile browsers exist to run many separate identities; a shared agent browser exists to give an agent your one real identity's sessions in a workspace that isn't your window. The isolation in Spaces is about tasks not colliding with each other or with you, not about disguising anything.
Doesn't a second browser waste memory?
It costs what a browser costs, and buys back the window you work in. For a few tasks a week, that trade can reasonably go either way; for daily parallel work, the five collisions above cost more attention than a browser process costs RAM. Also worth naming: the extension route runs its tasks in your browser's memory footprint anyway.
