Repository navigation
[CLI]: attach --extension can't find Windows-host extension on WSL2; working config needs undocumented env vars #42092
Description
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=chromefails 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=demoWith 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_DIRlooks 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-dirflag onattach). 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 --extensionshould be able to target a Windows host browser without relying onPWTEST_*env vars — e.g. via documented--executable-path/--user-data-dirflags onattach. - 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 [email protected] / [email protected]*, which has no attach command at all (Unknown command: attach) — yet its bundled SKILL.md documents attach --extension. The actively maintained CLI is @playwright/[email protected]. 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.
Activity
github-actions commentedon Aug 4, 2026
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 --extensionhas 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 readsexecutablePathfrom--executable-path/PLAYWRIGHT_MCP_EXECUTABLE_PATHand the channel from--browser/PLAYWRIGHT_MCP_BROWSER. Theattachcommand (program.ts) exposes--browserand--profile, but not--executable-pathand not--user-data-dir, and--profileisn't wired into the extension path at all — so on the CLI the only way to set the executable is thePLAYWRIGHT_MCP_EXECUTABLE_PATHenv var.createExtensionBrowser(extensionContextFactory.ts) resolves the profile asPWTEST_EXTENSION_USER_DATA_DIR ?? defaultUserDataDirForChannel(channel). There is no public flag or env var for it —PWTEST_EXTENSION_USER_DATA_DIRis genuinely a test variable (it's used only undertests/extension/), so you correctly identified the one knob that makes it work, and it's not meant to be user-facing.executablePathis 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 onattach.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)
attachlacks supported--executable-path/--user-data-dirflags for the extension flow, leaving onlyPWTEST_*; 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-clinpm package is a different, older package with noattachcommand, while@playwright/cliis 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
fix(mcp): mention PLAYWRIGHT_MCP_EXECUTABLE_PATH in extension not fou…
yury-s commentedon Aug 4, 2026
If you want to use host browser from WSL2 linux, you need to provide custom path via
PLAYWRIGHT_MCP_EXECUTABLE_PATHenv variable. We'll update the error message to mention that. You should not needPWTEST_EXTENSION_USER_DATA_DIRin this case, it's only for our own tests.