[Bug] Extension attach to existing Edge tab leaves main world unusable until first Playwright navigation

[escape0707]

Summary

When I attach to an already-open Edge tab via playwright-cli open --extension and select that tab in Edge, the session partially works:

• tab-list, snapshot, console, and network work
• eval hangs
• input-style commands like hover hang

If I immediately run goto <current-url> after attach, eval and hover start working on that same session.

This looks like the selected existing tab is attached with a usable utility world, but not a usable main world, until the first Playwright-driven navigation.

Environment

• @playwright/cli: 1.59.0-alpha-1771104257000
• Node: v25.8.1
• OS: Arch Linux on WSL2
• Browser: Microsoft Edge on Windows, launched from WSL with:
  • PLAYWRIGHT_MCP_EXECUTABLE_PATH="/mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe"

CLI repro

1. Run:

export PLAYWRIGHT_MCP_EXECUTABLE_PATH="/mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe"
playwright-cli open --extension --browser=msedge

2. In Edge, choose an already-open regular web page tab to attach to.
3. Run:

playwright-cli tab-list
playwright-cli snapshot
playwright-cli eval "() => document.title"
playwright-cli hover <some-ref-from-snapshot>

Actual behavior

• tab-list works
• snapshot works
• eval hangs / times out
• hover hangs

Expected behavior

After selecting an existing tab, eval and DOM interaction commands should work without needing a forced navigation first.

Workaround

If I run:

playwright-cli goto <the-current-tab-url>

then both of these start working:

playwright-cli eval "() => document.title"
playwright-cli hover <some-ref-from-snapshot>

This reloads the page, so it is only a partial workaround.

Lower-level repro

Using Playwright's internal extension attach path directly, I can reproduce the same split:

• page.title() works immediately after attach
• page.evaluate(() => document.title) times out immediately after attach
• after await page.goto(page.url()), page.evaluate(() => document.title) works

I also found that direct Playwright locator.hover() can succeed before the navigation, which suggests there may be two related problems:

1. The attached existing tab does not have a usable main-world execution context until first Playwright navigation.
2. playwright-cli input-style commands appear to hang because their post-action completion path depends on page.evaluate(...).

Notes

Related but not exact matches:

• Playwright-MCP 0.0.22 is causing " Execution context was destroyed, most likely because of a navigation" failures with an existing browser #439
• Usage confusion regarding --extension. #1426
• [Bug] Extension mode loses the target tab context and starts acting on a chrome-extension:// page after manual browser interaction on Edge #1465

[yury-s]

I can't reproduce it, connects just fine from wsl to the host msedge. Maybe some policy intervenes? Does it happen with other web sites in the tab?

logs

yurys@CPC-yurys-CCDT0:/mnt/c/Users/yurys/cli$ PLAYWRIGHT_MCP_EXECUTABLE_PATH="/mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe" playwright-cli open --extension
### Browser `default` opened with pid 5800.
- default:
  - browser-type: chrome
  - user-data-dir: <in-memory>
  - headed: false
---
### Page
- Page URL: https://playwright.dev/
- Page Title: Fast and reliable end-to-end testing for modern web apps | Playwright
### Snapshot
- [Snapshot](.playwright-cli/page-2026-03-30T21-33-36-565Z.yml)
yurys@CPC-yurys-CCDT0:/mnt/c/Users/yurys/cli$ playwright-cli eval "() => document.title"
### Result
"Fast and reliable end-to-end testing for modern web apps | Playwright"
### Ran Playwright code
\```js
await page.evaluate('() => document.title');
\```
yurys@CPC-yurys-CCDT0:/mnt/c/Users/yurys/cli$
\```

</details>

[escape0707]

I can reproduce it today on https://playwright.dev/ itself.

On my setup (WSL2 -> host Edge):

1. export PLAYWRIGHT_MCP_EXECUTABLE_PATH="/mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe"
2. playwright-cli open --extension
3. select an already-open https://playwright.dev/ tab
4. playwright-cli tab-list -> works
5. playwright-cli snapshot -> works
6. timeout 20s playwright-cli eval "() => document.title" -> times out
7. timeout 20s playwright-cli hover e9 -> times out

Then, in a fresh attached session to a already-open https://google.com/ tab:

1. playwright-cli open --extension
2. select the already-open https://google.com/ tab
3. playwright-cli goto https://playwright.dev/
4. playwright-cli eval "() => document.title" -> works
5. playwright-cli hover e9 -> works

So for me this is not limited to the original site; it reproduces on playwright.dev too. That seems to suggest an environment-specific or race-dependent attach problem rather than a site-specific policy issue. But I have no idea where to look into now.

[yury-s]

The same steps work fine for me for both URLs, I've tried with the latest (v0.1.2) playwright-cli. It has something to do with your environment, if not policy, maybe you another extension interferes.

[escape0707]

@yury-s I tried to see why I'm facing this problem. And I tried to reproduce in a fresh Windows 11 VM and also on my host Windows OS. Both works. But when I get back to my ArchWSL, I still face the same hanging. So I guess it's not about the site, nor about my browser setting or extension, but I don't know if it's because WSL or I didn't install some package that is a dependency and is included in Ubuntu but not in Arch.

I tried to let codex do some debugging, but to be honest I don't know if it figures the source of the problem correct, and I don't understand the project enough to judge.

If you have any suggestions on how I should debug/record, or how should I prompt codex to troubleshoot, I'd be glad to do so.

Anyway, below is my codex's final summary of the debug session, I'm not sure if it helps but I think I'll still paste it here:

---

Codex output

The maintainer likely can’t reproduce because this is a timing-sensitive attach race, not a deterministic “WSL always broken” bug.

What appears to happen on your machine:

• In --extension attach to an already-open tab, Playwright’s main-world execution context is sometimes missed during initialization.
• When that happens, utility-world features still work, so snapshot, tab-list, and page.title()-style paths look healthy.
• But main-world features hang: eval, localstorage-list, sessionstorage-list, and anything whose completion path calls page.evaluate(...).

Why that explains the maintainer difference:

• On their setup, the attach sequence probably receives Runtime.executionContextCreated after listeners are installed, so the main world is registered and everything works.
• On your setup, that event is likely emitted before the main-frame listener is ready, so the main world is never registered for the existing tab.
• That kind of race is inherently machine/environment dependent, so “works for me” is fully compatible with “hangs for you”.

Why I think this is the right explanation:

• Native Windows works for you, Arch WSL fails on the same machine. That rules out site policy and strongly points to an environment-sensitive timing issue.
• If you attach to an existing tab and then navigate after attach, things work. That fits a “fresh navigation recreates contexts” explanation.
• Live debugging showed:
  • snapshot works
  • cookie-list works
  • eval hangs
  • localstorage-list/sessionstorage-list hang
  • run-code "async page => page.url()" also hangs because the CLI completion helper itself ends with page.evaluate(...)
• Source matches that split:
  • Utility-world paths: /tmp/playwright-inspect/packages/playwright-core/src/server/frames.ts:1636, /tmp/playwright-inspect/packages/playwright-core/src/server/frames.ts:1777
  • Main-world evaluate paths: /tmp/playwright-inspect/packages/playwright-core/src/tools/backend/evaluate.ts:56, /tmp/playwright-inspect/packages/playwright-core/src/tools/backend/
    webstorage.ts:31
  • CLI completion also uses page.evaluate(...): /tmp/playwright-inspect/packages/playwright-core/src/tools/backend/utils.ts:31, /tmp/playwright-inspect/packages/playwright-core/src/tools/
    backend/tab.ts:467
  • Likely race point in Chromium attach init: Runtime.enable is sent before main-frame renderer listeners are added after Page.getFrameTree(): /tmp/playwright-inspect/packages/playwright-core/
    src/server/chromium/crPage.ts:467, /tmp/playwright-inspect/packages/playwright-core/src/server/chromium/crPage.ts:472, /tmp/playwright-inspect/packages/playwright-core/src/server/chromium/
    crPage.ts:664

So the answer is not “the maintainer is wrong” and not “your environment is mysterious”. It is more specific:

• The bug is probably real.
• It is probably in the existing-tab --extension attach path.
• It is probably a race around main-world execution-context registration.
• WSL changes timing enough to trigger it on your setup, while the maintainer’s setup misses the race window.

[escape0707]

I tested again in the VM because I forgot to test in ArchWSL inside the Windows VM. (Needs nested virtualization.)

It turns out I can consistently reproduce it in the fresh ArchWSL in a fresh Windows 11 VM. All I did is just:

1. Enable nested virtualization
2. wsl --install archlinux
3. pacman -Syu sudo pnpm
4. Configure user account with sudo and switch
5. pnpm add @playwright/cli
6. PLAYWRIGHT_MCP_EXECUTABLE_PATH="/mnt/c/Program Files (x86)/Microsoft/Edge/Application/ms
   edge.exe" pnpm exec playwright-cli attach --extension
7. pnpm exec playwright-cli --raw eval "() => document.title"

and get stuck.

So I'm not sure if it's a ArchWSL thing but since ArchWSL is also in the wsl install list, maybe this can help you reproduce it?

[yury-s]

Thanks for the detailed investigation. Per your own testing, this only reproduces with ArchWSL talking to a Windows-host Edge via --extension attach to an existing tab — not on native Windows, not in a Windows 11 VM, and not on our standard WSL setup. The trigger is narrow enough that we can't prioritize a fix.

Closing as won't-fix for now. Happy to reopen if it reproduces in a more common environment.