← 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:

ToolBrowser runs inSession stateCan access your logged-in Shopify?
Playwright MCPFresh Chromium, spawned per sessionEmpty — no cookies, no localStorage, no IndexedDBNo
BrowserBase MCPManaged cloud ChromiumEmpty — anonymous browser on their infrastructureNo
Firecrawl MCPServer-side crawlerPublic-web only — scrapes what anonymous visitors seeNo
Stagehand (when run via MCP wrapper)Fresh Playwright instanceEmpty unless you manually inject cookiesNo
Bardeen (Chrome extension)Your ChromeYour real sessionYes — 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:

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:

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:

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: