I started treating this as a separate bug class after seeing the same failure pattern repeat:

A human opens a browser profile and is logged in.
A Playwright script attaches through CDP.
The page opens.
Then the workflow behaves as if the session is empty, the account is logged out, or the request is coming from the wrong proxy.

The tempting fix is to add waits or rewrite selectors.

That is usually the wrong first move.

When a CDP-attached session loses auth state or proxy context, the first question is not:

Which selector changed?

It is:

Did my script attach to the same browser identity that I verified manually?

This note is a practical debugging checklist for that problem.

Problem: Playwright attaches to an existing Chromium browser, but cookies, session state, or proxy context do not match what I expected.

Scope: Chromium, connectOverCDP, browser profiles, persistent sessions, headless checks, and AI agent debugging.

Not covered: bypassing platform protections, CAPTCHA handling, or moving auth data between unrelated accounts.

The failure pattern

The run usually looks healthy from the outside.

The browser starts. The CDP endpoint responds. Playwright connects. The page loads. The script can click and read the DOM.

But the environment is wrong.

You may see one or more of these symptoms:

• Cookies are empty or fewer than expected.
• The app redirects to login after refresh.
• localStorage exists, but the app still treats the user as logged out.
• The account works manually but fails when attached through CDP.
• The public IP does not match the expected proxy route.
• The task works in visible mode but fails in headless mode.
• An AI browser agent retries the task and marks it successful from a different context.

That last case is especially easy to miss.

A normal script often stops when the environment changes. An AI agent may continue, adapt, and hide the real bug.

So before debugging selectors, I try to prove one thing:

The script is running from the expected browser identity.

First separate three persistence models

Before debugging, name the model you are actually using.

A lot of Playwright session bugs become confusing because these three models are mixed together:

• storageState
• launchPersistentContext
• connectOverCDP

They are related, but they are not interchangeable.

1. storageState

storageState is a snapshot.

It is useful when auth is represented by cookies, localStorage, and sometimes IndexedDB.

It is not the same thing as a full browser profile.

Good fit:

• test accounts
• repeatable login setup
• CI workflows
• clean browser contexts

Risky assumption:

My real Chrome profile is logged in, so storageState must contain everything.

It may not.

Some apps also involve sessionStorage, service workers, extensions, device-bound state, or app-specific storage.

2. launchPersistentContext

launchPersistentContext starts a browser with a specific user data directory.

That directory stores browser session data such as cookies and localStorage.

Good fit:

• long-lived automation profile
• local debugging
• workflows where the profile directory is the source of truth

Risky assumption:

I can point multiple browser instances at the same profile directory.

Do not do that.

Treat the user data directory like a lockable database. One browser owns it during the run.

3. connectOverCDP

connectOverCDP attaches Playwright to an existing Chromium browser over the Chrome DevTools Protocol.

Good fit:

• attaching to a browser started by another tool
• debugging an already-open profile
• connecting automation to a manually inspected session

Risky assumption:

CDP attachment gives me the exact same behavior as a Playwright-launched browser.

It often works well, but it is not the same connection model. When the bug involves cookies, profiles, or proxy context, verify the attached browser before touching the task logic.

Step 1: start a dedicated browser profile

Do not debug this against your daily Chrome profile.

Use a dedicated automation directory:

google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/pw-cdp-profile \
  --no-first-run

Then log in manually in that browser if the test requires an authenticated state.

Checklist:

• userDataDir is dedicated to this test.
• No other Chrome process is using the same directory.
• The browser was started with the expected remote debugging port.
• The profile is not your personal default Chrome profile.
• The profile can be reopened manually and still shows the expected login state.

Validation standard:

The profile must be trusted manually before it is trusted by automation.

If the manual browser is already logged out, Playwright is not the problem yet.

Step 2: attach through CDP and inspect the actual context

Run the smallest possible script before running your real workflow.

import { chromium } from "playwright";

const browser = await chromium.connectOverCDP("http://127.0.0.1:9222");
const context = browser.contexts()[0];

if (!context) {
  throw new Error("No browser context found. Check the CDP endpoint.");
}

const page = context.pages()[0] ?? await context.newPage();

const cookies = await context.cookies();
const storage = await page.evaluate(() => ({
  url: location.href,
  localStorageKeys: Object.keys(localStorage),
  sessionStorageKeys: Object.keys(sessionStorage),
}));

console.log({
  contextCount: browser.contexts().length,
  pageCount: context.pages().length,
  cookieCount: cookies.length,
  storage,
});

Do not skip this.

Checklist:

• contextCount is what you expected.
• pageCount is what you expected.
• The script is using the expected tab or creates a new tab in the expected context.
• cookieCount is not unexpectedly zero.
• localStorageKeys match the app you logged into.
• sessionStorageKeys are not the only place where auth appears to live.
• Reloading the page does not immediately redirect to login.

If this minimal script fails, the real workflow is irrelevant.

The problem is the attached browser context.

Step 3: check whether cookies are actually the auth source

A common debugging mistake is treating cookies as the whole session.

For many apps, that is not true.

Check each layer:

• Cookies
• localStorage
• IndexedDB
• sessionStorage
• service worker state
• extension state
• app-specific device or session binding

A useful question is:

Can I explain the login state using only the data that Playwright can see?

Use this snapshot for inspection, not as a blind copy-paste mechanism:

const state = await context.storageState({ indexedDB: true });

console.log({
  cookies: state.cookies.map(cookie => ({
    name: cookie.name,
    domain: cookie.domain,
    path: cookie.path,
    secure: cookie.secure,
    sameSite: cookie.sameSite,
  })),
  origins: state.origins.map(origin => ({
    origin: origin.origin,
    localStorageKeys: origin.localStorage.map(item => item.name),
  })),
});

Notice that this logs metadata, not secret values.

Checklist:

• Required cookie domains match the current URL.
• Required cookie paths are not too narrow.
• Required cookies are not expired.
• Secure cookies are used over HTTPS.
• SameSite behavior makes sense for the redirect flow.
• IndexedDB is checked when the app stores auth there.
• sessionStorage is considered if login disappears across new tabs or reloads.
• No auth values are printed into CI logs.

Validation standard:

Do not call it a cookie bug until you know where the app stores auth.

Step 4: verify the proxy from inside the attached session

The page loading is not enough.

The page must load through the expected network identity.

Run an IP check from the same attached page:

await page.goto("https://api.ipify.org?format=json", {
  waitUntil: "domcontentloaded",
});

console.log("public ip:", await page.textContent("body"));

For production systems, replace the public endpoint with your own internal IP echo service.

Checklist:

• Observed public IP matches the expected proxy group.
• Observed IP region matches the profile plan.
• Timezone, locale, and language are consistent with that region.
• The proxy was configured at the layer you think it was configured at.
• The CDP-attached browser and the headless worker do not use different proxy paths.
• Retry logic does not switch to another proxy silently.

Validation standard:

A run is valid only when these match:

• profile ID
• browser profile directory
• CDP endpoint
• cookie state
• storage state
• proxy route
• IP region
• execution mode

If the IP is wrong, stop debugging selectors.

Step 5: compare headed, CDP-attached, and headless behavior

When a workflow works manually but fails in automation, compare the environments side by side.

Use this matrix:

The goal is not to make every number identical.

The goal is to explain every difference.

Red flags:

• CDP-attached Playwright has fewer cookies than manual mode.
• Headless uses a different proxy than headed mode.
• The same URL redirects differently in each mode.
• The profile path is different but the run log does not show it.
• The agent retry opens a fresh context instead of the attached context.

Validation standard:

A headed success does not prove headless readiness. A CDP connection does not prove profile correctness.

Step 6: add stop conditions before an AI agent continues

This is where AI agent debugging differs from script debugging.

A deterministic script often fails loudly.

An agent can adapt and continue.

That is useful for UI variation, but dangerous for identity mismatch.

Before giving an agent a logged-in browser, require environment checks.

Stop the agent when:

• cookie count drops unexpectedly.
• The page redirects to login.
• public IP does not match the expected proxy.
• IP region changes during retry.
• timezone and proxy region disagree.
• localStorage or IndexedDB is empty when it should not be.
• The agent is not operating in the expected CDP-attached context.
• The page enters wallet, payment, account settings, deletion, permission, or destructive flows.
• The agent cannot produce a run log that ties result to profile, proxy, time, and mode.

A good agent run should answer:

• Which profile did I use?
• Which browser context did I attach to?
• Which proxy route did I use?
• What IP did the page observe?
• What session state did I verify before acting?
• Why was I allowed to continue?
• What would have made me stop?

If the agent cannot answer those, it should not act on a logged-in session.

Step 7: use a small run log for every debug attempt

The log does not need to be fancy.

It just needs to capture the identity of the run.

Example fields:

run_id: 2026-05-30-cdp-auth-debug-001
mode: cdp-attached
cdp_endpoint: http://127.0.0.1:9222
profile_label: qa-us-account-03
user_data_dir: /tmp/pw-cdp-profile
expected_proxy_region: US
observed_public_ip: 203.0.113.10
cookie_count_before: 18
cookie_count_after_reload: 18
local_storage_origins:
  - https://app.example.test
indexeddb_checked: true
landing_url_after_reload: https://app.example.test/dashboard
agent_allowed_to_continue: false
stop_reason: proxy_region_not_verified

This prevents vague debugging notes like:

It worked locally but failed in the agent.

That sentence is not enough.

A better note is:

The CDP-attached run used the expected profile and cookie count, but the observed IP did not match the expected proxy region, so the agent was stopped before account actions.

That is debuggable.

Common causes and first checks

Cause 1: wrong browser was attached

Symptoms:

• context.cookies() returns fewer cookies than expected.
• The page is logged out even though another Chrome window is logged in.
• The CDP port belongs to an older browser process.

First checks:

• Kill all test Chrome processes.
• Start one browser with one userDataDir.
• Reopen the CDP endpoint.
• Print browser.contexts().length.
• Print the current URL and cookie count before running actions.

Cause 2: wrong profile directory

Symptoms:

• Login works in one browser, but CDP sees a clean session.
• The app asks for first-time setup.
• The cookie jar is empty.

First checks:

• Confirm the exact userDataDir used at launch.
• Check chrome://version manually.
• Do not use the daily default Chrome profile.
• Do not let two browser instances share the same directory.

Cause 3: auth is not only stored in cookies

Symptoms:

• Cookies exist, but the app still logs out.
• Login survives reload but not a new tab.
• OAuth callback succeeds but dashboard redirects back to login.

First checks:

• Inspect localStorage.
• Inspect IndexedDB.
• Check sessionStorage.
• Check service worker and extension dependencies.
• Verify cookie domain, path, Secure, and SameSite.

Cause 4: proxy context drifted

Symptoms:

• The page loads but shows another region.
• Some accounts see different layouts.
• Verification prompts appear only in automation.
• Headless tasks produce different results from visible sessions.

First checks:

• Check public IP inside the attached page.
• Compare IP, region, timezone, and locale.
• Verify where the proxy is configured.
• Disable silent proxy failover during debugging.
• Record proxy identity with every run.

Cause 5: the AI agent retried from another context

Symptoms:

• The first attempt fails.
• The retry succeeds.
• The result is not reproducible manually.
• Logs do not show which profile or proxy was used.

First checks:

• Disable automatic retry.
• Require pre-run identity checks.
• Require post-run identity checks.
• Stop if the retry changes profile, context, proxy, or mode.

Recovery checklist

When the session or proxy context looks wrong, I use this order:

1. Stop the workflow.
2. Save screenshot, URL, cookie count, storage keys, and observed IP.
3. Close the attached browser.
4. Kill stale Chrome processes.
5. Restart one browser with the expected userDataDir and CDP port.
6. Manually confirm login state.
7. Reattach Playwright.
8. Re-run the minimal inspection script.
9. Verify cookies, localStorage, IndexedDB, and sessionStorage assumptions.
10. Verify proxy, IP region, timezone, and locale.
11. Run one low-risk page read.
12. Only then run the real workflow.

Do not recover by blindly copying cookies across unrelated profiles.

That often creates a more confusing state than the original bug.

What a trustworthy run looks like

A Playwright CDP run is trustworthy when you can prove:

• Correct browser instance
• Correct CDP endpoint
• Correct browser profile
• Expected cookie count
• Expected storage origins
• Auth source understood
• Expected proxy route
• Expected IP region
• Expected timezone and locale
• Same behavior after reload
• Headed and headless differences explained
• AI agent stop conditions enabled
• Run evidence saved

The important shift is this:

The browser opening is not proof.
The page loading is not proof.
The task completing is not proof.

For profile-based automation, the proof is that the task ran from the expected browser identity.

Final note

As soon as you manage more than a few profiles, this debugging problem becomes less about one script and more about operational visibility.

You need to know which browser profile, which session state, which proxy route, which execution mode, and which agent decision produced the result.

A profile-aware browser automation workspace can help keep those relationships visible, but the debugging principle stays the same:

Before asking whether automation worked, verify which identity it worked from.