← Tap · Blog

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

April 22, 2026 · Leon Ting · 7 min read

I asked Claude Code to summarize my unfulfilled Shopify orders this morning. Claude reached for its browser tool. The tool opened a fresh Chromium instance, 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 small friction points at something structural. The MCP browser tools shipping today — Playwright MCP, BrowserBase MCP, Firecrawl MCP — all solve browser automation for AI agents. None of them can touch your real accounts.

That's not a missing feature. It's an architectural property of where the browser runs.

## What each MCP browser tool actually does

Pull their source and read what `browser_navigate` and `browser_extract` mean in each:

Tool | Browser runs in | Session state | Can access your logged-in Shopify?
--- | --- | --- | ---
Playwright MCP | Fresh Chromium, spawned per session | Empty — no cookies, no localStorage, no IndexedDB | No
BrowserBase MCP | Managed cloud Chromium | Empty — anonymous browser on their infrastructure | No
Firecrawl MCP | Server-side crawler | Public-web only — scrapes what anonymous visitors see | No
Stagehand (when run via MCP wrapper) | Fresh Playwright instance | Empty unless you manually inject cookies | No
Bardeen (Chrome extension) | Your Chrome | Your real session | Yes — but no MCP, visual-only

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

## Why this gap is architectural, not a bug

Cloud browser tools can't just "add login support." The reasons are structural:

### 1. Cookies can't legally or safely travel to a cloud browser

Your `shopify.com` session cookie is scoped to your device. Even if a cloud service asked for it, you'd be handing over the actual authentication token to a third party. That's a liability the user doesn't want, and a liability the vendor doesn't want.

Some tools try to sidestep this by having you log in through them. But then they hold your credentials. Same problem, slightly laundered.

### 2. Browser fingerprints betray cloud origin

Many services — Google, LinkedIn, most banks — flag logins from unfamiliar IP / device fingerprints. A browser spawned on an AWS host will trip 2FA, device verification, or an outright block, even if you somehow shared the right cookie.

The only fingerprint that won't trip these is the one on your actual machine.

### 3. 2FA and re-auth flows need you physically present

Even if the cookie worked and the fingerprint didn't trip detection, a session renewal will ask for TOTP or a device prompt. The cloud browser can't answer. The human sitting at the cloud browser's owner's desk also can't — because they're not at that browser.

These three combine into a hard wall: cloud browsers cannot sustainably operate on a real user's authenticated accounts, no matter how much engineering is thrown at it.

## What real AI-agent work actually looks like

If you list the automations people actually want their Claude Code / Cursor / Cline agents to run, the auth-walled ones dominate:

- "Every morning, summarize my Shopify unfulfilled orders to Slack" — Shopify admin requires auth
- "Pull this week's closed-won deals from HubSpot into Notion" — HubSpot requires auth
- "Check my Wise balance and alert if below $X" — banking requires auth
- "Download PDF invoices from my three vendor portals" — vendor portals require auth
- "Read my Gmail for contracts and summarize obligations" — Gmail requires auth
- "Check whether our staging environment deployed the latest commit" — company dashboards require auth
- "Pull active conversations from Intercom and route to CRM" — Intercom requires auth

None of these are solvable by Playwright MCP, BrowserBase, or Firecrawl. Not because those tools are bad — they're all excellent at what they do. But what they do is operate on the public web or a fresh sandbox, and your real work lives in logged-in surfaces.

## The category nobody named yet: authenticated browser MCP

This is a coherent category with clear requirements:

- Runs in the user's real Chrome (or their real Playwright browser, if they use Chromium-based profiles)
- Operates on the user's real session — whatever cookies, localStorage, IndexedDB are already there
- Accessible to AI agents over MCP, not visual-only like a Bardeen or a PhantomBuster
- Doesn't send the user's data to any cloud — the whole blast radius is the user's local device
- Produces reusable, inspectable, versionable automation programs, not one-shot actions

There's exactly one MCP server in that quadrant today that I'm aware of: Tap. Not because Tap is clever — because the architectural constraints force this shape, and nobody else started from those constraints.

## How Tap fills the gap

Tap is an MCP server that does three things:

1. Forge: "Track my Shopify unfulfilled orders" → AI inspects shopify.com, finds the stable structured sources (API endpoints, ARIA landmarks, Schema.org markup, RSS when available), compiles a deterministic program that reads from the most stable source. No per-step LLM call at runtime.
2. Run: the program runs in your local Chrome (or Playwright on your machine, or macOS) using your real session. Your 2FA state, your device fingerprint, your cookies — all of it is already there because it's your browser.
3. Doctor: when the site structure drifts in a way that would break the program, Tap detects it before your data goes wrong. Not a generic "the script crashed" signal — a structural drift detector that knows what the program was supposed to read.

The thing Tap does that a cloud competitor can't is step 2. Steps 1 and 3 are replicable. Step 2 is architectural.

## When cloud browser MCP is the right choice

To be clear — cloud browser MCP tools aren't inferior, they're specialized:

- Firecrawl is the best tool for scraping public content at scale for RAG pipelines
- BrowserBase is the best tool for running scheduled public-web automation without tying up your local machine
- Playwright MCP is the best tool for testing your own web app against a clean-state browser

Use them when the target data is public. Use an authenticated browser MCP when the target data is behind your login.

## Try it

If you're using Claude Code or Cursor and you've hit the "Log in to continue" wall, install Tap:

### Install (60 seconds)

    curl -fsSL https://taprun.dev/install.sh | bash
    tap mcp stdio            # point your MCP host (Claude Code / Cursor / Cline / Continue) at this command

Then ask Claude Code to call `capture` on one of the auth-walled tasks above. Tap inspects using your logged-in session and emits a deterministic Plan. The plan is yours — inspectable at `~/.tap/plans/<site>/<name>.plan.json`, re-runnable at zero AI cost, drift-detected by `tap verify` when the site changes.

Free tier is substantial: 70+ community-built taps, full `verify`, deterministic-template `capture`, MCP read ops. Paid tiers unlock AI-assisted `capture` for the long tail (Capture $19/mo, up to 5 saved plans) and the 3-path repair pipeline (Repair $49/mo, up to 20 saved plans).

If Claude Code keeps hitting login walls for you, that wall is not going away — the cloud MCP tools are architecturally on the wrong side of it. Tap is on your side.

Related reading:

- Stagehand vs Tap: AI browser automation compared
- Deterministic vs AI browser automation
- Programs beat prompts