[Bug]: cli-client extension mode rejects all browser-level CDP commands (cookie-list, state-save) with "Unsupported command without sessionId"

[riba2534]

What happened?

In MCP extension mode, all browser-level CDP commands fail with:

Error: Protocol error (Storage.getCookies): Unsupported command without sessionId: Storage.getCookies

This breaks every cli-client subcommand that touches browser-scoped state:

• playwright-cli cookie-list (and cookie-get / cookie-set / cookie-delete / cookie-clear)
• playwright-cli state-save

The browser session itself is healthy — goto, eval, snapshot, click all work fine. Only commands that hit Storage.* (and presumably Browser.* / target-less Target.*) are affected.

The same commands work correctly in non-extension (standalone) mode.

Root cause (already located)

The relay's forwardToExtension unconditionally requires a sessionId:

packages/playwright-core/src/tools/mcp/cdpRelayV2.ts (visible in shipped bundle around coreBundle.js:65914-65918):

async forwardToExtension(method, params, sessionId) {
  if (!sessionId)
    throw new Error(`Unsupported command without sessionId: ${method}`);
  return await this._model.sendCommand(sessionId, method, params);
}

But Storage.getCookies / Storage.setCookie / Storage.clearDataForOrigin etc. are browser-level CDP commands, routed by browserContextId, not by a target sessionId. The Playwright CRBrowser already calls them that way:

// coreBundle.js:35671
const { cookies } = await this._browser._session.send(
  "Storage.getCookies",
  { browserContextId: this._browserContextId }
);

So the relay's "must have sessionId" guard rejects commands that are legitimately session-less. This looks like a regression from the cli-client/extension-mode generalization landed in April–May 2026 (around #40191 / #40411).

Suggested fix

In cdpRelayV2.ts::forwardToExtension, route browser-level commands through the model's browser-level channel instead of throwing. Something like:

async forwardToExtension(method, params, sessionId) {
  if (!sessionId) {
    // browser-level CDP commands (Storage.*, Browser.*, target-less Target.*)
    // are routed by browserContextId, not by a target sessionId.
    if (method.startsWith('Storage.') || method.startsWith('Browser.'))
      return await this._model.sendBrowserCommand(method, params);
    throw new Error(`Unsupported command without sessionId: ${method}`);
  }
  return await this._model.sendCommand(sessionId, method, params);
}

(sendBrowserCommand may need to be added on BrowserModel to forward to the extension's root debugger session — happy to send a PR if that direction sounds right.)

Steps to reproduce

# 1. open browser in extension mode (relay to user's local Chrome)
PLAYWRIGHT_MCP_EXTENSION=true playwright-cli open
PLAYWRIGHT_MCP_EXTENSION=true playwright-cli goto https://example.com/

# 2. any cookie or state command fails
PLAYWRIGHT_MCP_EXTENSION=true playwright-cli cookie-list
# => ### Error
# => Error: Protocol error (Storage.getCookies): Unsupported command without sessionId: Storage.getCookies

PLAYWRIGHT_MCP_EXTENSION=true playwright-cli state-save /tmp/state.json
# => same error

# 3. but interaction commands work fine
PLAYWRIGHT_MCP_EXTENSION=true playwright-cli eval "document.title"
# => works

Same cookie-list against a standalone (non-extension) browser works correctly.

Expected behavior

In extension mode, cookie-list / cookie-get / state-save / etc. should return the cookies from the connected browser context — same behavior as in non-extension mode.

This matters because extension mode is the only way to read the user's logged-in HttpOnly cookies (e.g. for tooling that proxies authenticated requests through the user's existing browser session). document.cookie via eval is not a workaround for HttpOnly cookies.

Version

playwright-cli (@playwright/cli): 0.1.12
node: v25.8.2
OS: macOS 26.4.1 (arm64)
Chrome: connected via MCP extension

Workarounds

• ❌ Headless / standalone mode — works for cookie-list, but loses access to the user's logged-in session (defeats the purpose of extension mode).
• ❌ document.cookie via eval — only returns non-HttpOnly cookies; auth cookies are usually HttpOnly.
• ✅ Local patch to cdpRelayV2.ts along the lines suggested above.

Happy to send a PR if a maintainer can confirm the direction.

[riba2534]

Update — root cause bisected, and a one-line workaround exists

I bisected this between @playwright/cli@0.1.11 (works) and @playwright/cli@0.1.12 (broken). The bundled playwright/playwright-core dep moves from 1.60.0-alpha-1777669338000 (2026-05-01) to 1.60.0-alpha-1778101408000 (2026-05-06) — a 5-day window.

diff-ing the two coreBundle.js files, the cdpRelayV2.forwardToExtension body is byte-for-byte identical in both versions, and so is the cookieList tool implementation. The single semantic change is in packages/playwright-core/src/tools/mcp/protocol.ts:

- DEFAULT_VERSION = 1;   // 0.1.11 → defaults to cdpRelay v1, which forwards sessionId-less commands transparently
+ DEFAULT_VERSION = 2;   // 0.1.12 → defaults to cdpRelayV2, whose forwardToExtension throws on missing sessionId

Consumed at:

this._protocolVersion = parseInt(
  process.env.PLAYWRIGHT_EXTENSION_PROTOCOL ?? DEFAULT_VERSION.toString(),
  10
);

So this is a silent default flip: cdpRelayV2 was already in the tree but opt-in; bumping the default exposed its incomplete handling of browser-level CDP commands (Storage.* etc.) to every extension-mode user.

For comparison, the v1 path (still in the bundle, still working) just passes the (possibly undefined) sessionId straight to the extension:

// cdpRelay v1, unchanged across both versions
async forwardToExtension(method, params, sessionId) {
  if (this._connectedTabInfo?.sessionId === sessionId) sessionId = void 0;
  return await this._sendCommand("forwardCDPCommand", { sessionId, method, params });
}

Workaround (no patch / no downgrade needed)

Set the env var to pin the protocol back to v1:

PLAYWRIGHT_EXTENSION_PROTOCOL=1 PLAYWRIGHT_MCP_EXTENSION=true playwright-cli cookie-list --domain example.com

Verified on @playwright/cli@0.1.12: with PLAYWRIGHT_EXTENSION_PROTOCOL=1, cookie-list returns full HttpOnly cookies; without it, the same command throws Unsupported command without sessionId: Storage.getCookies as originally reported.

Suggested triage

Either:

1. Revert DEFAULT_VERSION to 1 until cdpRelayV2 handles browser-level CDP methods — keeps users on the proven path.
2. Fix cdpRelayV2::forwardToExtension to route Storage.* / Browser.* through the model's browser-level channel before flipping the default (per my original suggestion above).

Option 2 is the right long-term fix; option 1 is a fast revert that unbreaks current users today.