Playwright MCP Authentication: How to Keep AI Agents Logged In (2026)

The first demo of the Playwright MCP Server always goes well: you ask Claude to open a public page, click around, and write a test. Then you point it at your real app — the one behind a login screen — and everything falls apart. The agent logs in on every run. It hits rate limits. It triggers "new device" security emails. It gets stuck on a 2FA prompt it cannot answer.

Authentication is the biggest "Day 2" problem in AI-powered browser testing. The good news: Playwright already has the tools to solve it — storage state, persistent profiles, and isolated sessions. This guide shows you how to wire them into the Playwright MCP Server so Claude stays logged in, safely, across every run.

Why Authentication Breaks AI Browser Agents

A human tester logs in once in the morning and stays logged in all day. An AI agent driving a fresh browser starts every session with no cookies and no local storage. Unless you give it a session, it has to repeat the login flow each time. That causes real problems:

The fix is the same one Playwright has recommended for regular tests for years: log in once, save the authenticated state, and reuse it.

How Playwright MCP Browser Sessions Work

The official @playwright/mcp server can run the browser in two modes, and they behave very differently when it comes to logins:

Persistent profiles are convenient, but the state is hidden in a folder you did not create and it drifts over time. For anything you want to be repeatable, isolated mode plus a storage state file is the professional choice. Let us set up both.

Step 1: Save a Storage State File

A storage state file is a JSON snapshot of cookies and local storage for your app. The fastest way to create one is with Codegen — you log in by hand, and Playwright saves the session when you close the window:

# Opens a browser — log in manually, then close the window
npx playwright codegen https://staging.example.com/login \
  --save-storage=playwright/.auth/user.json

You can also generate it programmatically with a Playwright setup project, which is the better option for CI because it runs automatically and keeps the file fresh:

import { test as setup, expect } from '@playwright/test';

const authFile = 'playwright/.auth/user.json';

setup('authenticate', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL!);
  await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD!);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();

  // Save cookies + localStorage for reuse
  await page.context().storageState({ path: authFile });
});

Credentials come from environment variables, never from source code. If you are new to login flows in Playwright, the Playwright login test tutorial covers the basics.

Step 2: Load the Session into the Playwright MCP Server

Now point the MCP server at that file. With Claude Code, add the server in isolated mode and pass the storage state:

claude mcp add playwright -- npx @playwright/mcp@latest \
  --isolated \
  --storage-state=playwright/.auth/user.json

If you configure MCP servers with JSON (Claude Desktop, Cursor, VS Code), the equivalent entry is:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--isolated",
        "--storage-state=playwright/.auth/user.json"
      ]
    }
  }
}

Every new browser session now starts already logged in. Ask Claude to open /dashboard and it lands there directly — no login form, no credentials in the prompt. For the rest of the server options, see the Playwright MCP Server setup guide.

Step 3: Reuse the Same Session in Generated Tests

The tests Claude writes should use the exact same authentication as the exploration session. Configure a setup project and make your browser projects depend on it:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'setup', testMatch: /.*\.setup\.ts/ },
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        storageState: 'playwright/.auth/user.json',
      },
      dependencies: ['setup'],
    },
  ],
});

Now the setup project logs in once per test run, every test starts authenticated, and the MCP server reads the same file. Tell Claude about this in your prompt or project instructions so it does not add login steps to every generated test:

## Testing conventions
- Tests run pre-authenticated via playwright/.auth/user.json.
- Never add login steps to generated tests.
- Never ask for or type real credentials. Use the saved session.
- For logged-out scenarios, use test.use({ storageState: { cookies: [], origins: [] } }).

Handling MFA, 2FA & SSO Logins

Multi-factor authentication is where most AI agent setups get stuck. You have four realistic options, from best to worst:

1. Use a dedicated test account without MFA in staging — restricted to non-production data. This is the simplest and most common approach.
2. Automate TOTP codes in your setup project. If the account uses an authenticator app, store the TOTP secret as a CI secret and generate the code with a library like otplib. The agent never sees the secret — only the resulting session.
3. Log in manually once with Codegen (--save-storage), completing SSO or MFA yourself, and reuse the file until the session expires.
4. Bypass at the API level — some apps support a test-only token endpoint. Call it with Playwright's request fixture and inject the resulting cookie. Only do this with backend team approval.

Security Best Practices for Auth Files

A storage state file is effectively a logged-in session in a JSON file. Anyone who has it can act as that user until it expires. Treat it like a password:

• Git-ignore it. Add playwright/.auth/ (and any --user-data-dir folder) to .gitignore before your first commit.
• Use test accounts only. Never save a session for a real admin or customer account.
• Keep credentials in env vars or a secrets manager. Never paste passwords into a Claude prompt or a CLAUDE.md file.
• Regenerate often. Let the setup project create a fresh file on every CI run instead of caching old sessions.
• Limit what the agent can reach. Point MCP sessions at staging, and use the server's allowed-origins options to keep the agent on your domains.

# Playwright auth sessions — never commit
playwright/.auth/
.mcp-profile/

Troubleshooting: Agent Still Sees the Login Page

Frequently Asked Questions

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn