[CLI]: attach --extension can't find Windows-host extension on WSL2; working config needs undocumented env vars

[0anton]

What's going on

On WSL2, playwright-cli attach --extension=<browser> cannot discover the Playwright Extension running in a Windows Chrome/Edge, and the config that does work relies on undocumented environment variables (there are no CLI flags for it). This is a WSL host/guest split: the CLI runs in the Linux guest, but the only browser with the extension installed is the Windows host browser.

1. Misleading failure with the documented flags

Running exactly what the docs describe (extension installed in Windows Chrome, token from the extension status page):

export PLAYWRIGHT_MCP_EXTENSION_TOKEN='<token>'
npx -y @playwright/cli@latest attach --extension=chrome

fails with:

Error: Playwright Extension not found in "/home/<user>/.config/google-chrome".
Install it from https://chromewebstore.google.com/detail/playwright-extension/mmlmfjhmonkocbjadbfplnigmagldckm
    at createExtensionBrowser (.../playwright-core/lib/coreBundle.js)
    at async createBrowserWithInfo (...)
Error: Daemon pid=<pid>: Daemon process exited with code 1

The extension is installed — just in the Windows Chrome profile, not the Linux profile ~/.config/google-chrome that the CLI checks. The error message is misleading: it tells the user to install an extension that is already installed, and gives no hint that a Windows profile / host browser is involved.

2. The working configuration requires undocumented env vars

attach only exposes --cdp, --endpoint, --extension, --config, --session (per playwright-cli --help attach). There is no --executable-path and no --user-data-dir flag. The only way to point it at the Windows browser is via env vars that aren't documented for this flow:

export PLAYWRIGHT_MCP_EXTENSION_TOKEN='<token>'
export PLAYWRIGHT_MCP_BROWSER='chrome'
export PLAYWRIGHT_MCP_EXECUTABLE_PATH='/mnt/c/Program Files/Google/Chrome/Application/chrome.exe'
export PWTEST_EXTENSION_USER_DATA_DIR='/mnt/c/Users/<user>/AppData/Local/Google/Chrome/User Data'
npx -y @playwright/cli@latest attach --extension=chrome --session=demo

With these set, it works correctly:

### Session `demo` created, attached to `chrome`.
### Page
- Page URL: chrome-extension://mmlmfjhmonkocbjadbfplnigmagldckm/connect.html?mcpRelayUrl=ws%3A%2F%2F127.0.0.1%3A41791%2Fextension%2F...&token=<redacted>
- Page Title: Welcome
### Snapshot
- [Snapshot](.playwright-cli/page-...yml)

Two problems here:

• PWTEST_EXTENSION_USER_DATA_DIR looks like an internal test variable, yet it is the only knob that makes the extension flow work on WSL. If it is the supported mechanism, it should be documented (and ideally surfaced as a proper --user-data-dir flag on attach). If not, there should be a supported flag.
• The relay URL is now correctly IPv4 (ws://127.0.0.1:...), so the earlier IPv6 issue [Bug]: WSL extension relay emits IPv6 loopback URL unreachable from Windows Edge #41180 appears fixed. This report is about the earlier extension-discovery step, not the relay URL.

Expected behavior

• On WSL2, attach --extension should be able to target a Windows host browser without relying on PWTEST_* env vars — e.g. via documented --executable-path / --user-data-dir flags on attach.
• When the extension genuinely can't be found, the error should mention which profile/path was checked and note the WSL host-browser case, rather than unconditionally telling the user to install an already-installed extension.

Environment

• OS: Windows 11 + WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)
• Browser with extension: Windows Chrome, Playwright Extension installed
• Node: v24.14.1, npx 11.11.0

Note on package naming (separate, minor)

npx playwright-cli (the bare package name) resolves to playwright-cli@0.262.0 / playwright-core@1.59.0-alpha-*, which has no attach command at all (Unknown command: attach) — yet its bundled SKILL.md documents attach --extension. The actively maintained CLI is @playwright/cli@0.1.17. Users following the skills docs with the bare playwright-cli package hit a dead end. Consider deprecating/redirecting the playwright-cli npm package to @playwright/cli.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at this.

Valid request — the source confirms exactly what you found. On the extension flow, attach --extension has no way to point at a host browser except through two env vars, one of which (PWTEST_EXTENSION_USER_DATA_DIR) is a test-only knob, and the "not found" error only ever names the local Linux profile. This is WSL-agnostic — it's just the only place the host/guest split bites.

Details from reading the code:

Why the documented flow fails and only the env vars work

• resolveExtensionOptions (config.ts) only reads executablePath from --executable-path/PLAYWRIGHT_MCP_EXECUTABLE_PATH and the channel from --browser/PLAYWRIGHT_MCP_BROWSER. The attach command (program.ts) exposes --browser and --profile, but not --executable-path and not --user-data-dir, and --profile isn't wired into the extension path at all — so on the CLI the only way to set the executable is the PLAYWRIGHT_MCP_EXECUTABLE_PATH env var.
• createExtensionBrowser (extensionContextFactory.ts) resolves the profile as PWTEST_EXTENSION_USER_DATA_DIR ?? defaultUserDataDirForChannel(channel). There is no public flag or env var for it — PWTEST_EXTENSION_USER_DATA_DIR is genuinely a test variable (it's used only under tests/extension/), so you correctly identified the one knob that makes it work, and it's not meant to be user-facing.
• When executablePath is set, that same function skips the profile check entirely — the code even has a comment calling out your exact case: "Custom executablePath may target a browser in a different filesystem (e.g. Windows chrome.exe from WSL2), so the local profile path is not meaningful." So the escape hatch exists internally; it just isn't surfaced as supported CLI flags on attach.
• The error Playwright Extension not found in "<path>" does include the path it checked, but nothing about a host browser / custom executable being an option — so on WSL it reads as "install the thing you already installed."

So both of your asks are well-founded: (1) attach lacks supported --executable-path / --user-data-dir flags for the extension flow, leaving only PWTEST_*; and (2) the not-found error should point at the host-browser/custom-executable path instead of unconditionally telling you to reinstall.

The package-naming note is a separate, real thing too: the bare playwright-cli npm package is a different, older package with no attach command, while @playwright/cli is the maintained one. Worth splitting into its own issue if a maintainer wants to track the deprecation/redirect.

I didn't spin up a WSL2 host/guest setup to reproduce end-to-end — this one is settled by the source rather than a run, and your working-vs-failing configs already pin it down precisely. Leaving the flag-vs-env design call and priority to the maintainers.

_{Triaged by the Playwright bot - agent run}

[yury-s]

If you want to use host browser from WSL2 linux, you need to provide custom path via PLAYWRIGHT_MCP_EXECUTABLE_PATH env variable. We'll update the error message to mention that. You should not need PWTEST_EXTENSION_USER_DATA_DIR in this case, it's only for our own tests.