DEV Community

Leon
Leon

Posted on • Originally published at taprun.dev

The authenticated browser MCP — why cloud tools can't see your logged-in state

I asked Claude Code to summarize my unfulfilled Shopify orders this morning. Claude reached for its browser tool. The tool opened a fresh Chromium, navigated to admin.shopify.com, and came back with: "Log in to continue."

Of course. My browser is logged in. Claude's browser isn't.

This isn't a missing feature. It's an architectural property of where the browser runs.

What each MCP browser tool actually does

Pull their source. What browser_navigate and browser_extract actually mean differs by tool:

Tool Browser runs in Session state Can access your Shopify admin?
Playwright MCP Fresh Chromium, spawned per session Empty No
Browserbase MCP Managed cloud Chromium Empty No
Firecrawl MCP Server-side crawler Public web only No
Stagehand (via MCP wrapper) Fresh Playwright Empty unless cookies injected No
Bardeen (Chrome extension) Your Chrome Your real session Yes — but no MCP, visual-only

Four technically excellent tools, all architecturally blind to 90% of your web workflow: SaaS accounts, vendor portals, internal dashboards, email.

Why this gap is architectural, not a bug

Three structural reasons cloud browsers can't "just add login support":

1. Cookies can't legally or safely travel to a cloud browser. Your shopify.com session cookie is scoped to your device. Handing it to a third party = handing over the auth token. Liability nobody wants.

2. Browser fingerprints betray cloud origin. Google / LinkedIn / most banks flag logins from unfamiliar IP and device fingerprints. A browser spawned on AWS trips 2FA, device verification, or an outright block, even with the right cookie.

3. 2FA and re-auth flows need you physically present. TOTP prompts. Device approval. Push notifications. The cloud browser can't answer; the human at the cloud browser's owner's desk also can't — because they're not at that browser.

Hard wall. No amount of engineering routes around it.

What real agent work actually looks like

The automations people want from Claude Code / Cursor / Cline are mostly auth-walled:

  • Summarize my Shopify unfulfilled orders to Slack
  • Pull this week's closed-won HubSpot deals into Notion
  • Check my Wise balance and alert if low
  • Download PDF invoices from vendor portals
  • Read Gmail for contracts and summarize obligations
  • Verify staging deployed the latest commit
  • Route Intercom conversations to CRM

None solvable by Playwright MCP, Browserbase, or Firecrawl. Not because they're bad — but because what they do is operate on the public web. Your real work lives behind logins.

The category: authenticated browser MCP

Requirements:

  • Runs in your real Chrome (or your real Playwright profile)
  • Operates on your real session — whatever cookies/localStorage/IndexedDB are already there
  • Accessible to AI agents over MCP — not visual-only
  • Nothing leaves your machine — blast radius = your local device

Tap is currently in this quadrant. Not because it's clever — because the constraints force this shape, and no other server started from these constraints.


Full architectural breakdown + the "compile once, replay forever" angle: The authenticated browser MCP →

Install: brew install LeonTing1010/tap/taprun. Free during v0.x.

Top comments (0)