[Bug]: WSL extension relay emits IPv6 loopback URL unreachable from Windows Edge

[escape0707]

Version

@playwright/cli@0.1.13 with playwright-core@1.61.0-alpha-1778188671000

Playwright Extension: 0.2.1

Steps to reproduce

This reproduces with the Playwright CLI extension attach flow on WSL2 when launching Windows Microsoft Edge via PLAYWRIGHT_MCP_EXECUTABLE_PATH.

No target website or application code is required; the failure happens before the extension relay connection is established.

1. Use WSL2 with @playwright/cli@0.1.13 installed.
2. Install Playwright Extension 0.2.1 in a Windows Microsoft Edge profile.
3. From WSL2, run:

export DEBUG='pw:mcp:relay'
export PLAYWRIGHT_MCP_BROWSER='msedge'
export PLAYWRIGHT_MCP_EXTENSION_TOKEN='<token from extension status page>'
export PLAYWRIGHT_MCP_EXECUTABLE_PATH='/mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe'
export PWTEST_EXTENSION_USER_DATA_DIR='<Windows Edge User Data path>'

playwright-cli attach --extension=msedge --session=repro

4. Observe the Playwright Extension connect.html tab that opens in Windows Edge.

In the failing case, the generated URL contains an IPv6 loopback relay endpoint like:

chrome-extension://mmlmfjhmonkocbjadbfplnigmagldckm/connect.html?mcpRelayUrl=ws%3A%2F%2F%5B%3A%3A1%5D%3A44386%2Fextension%2F<uuid>&client=...&protocolVersion=2&token=<redacted>

Decoded:

mcpRelayUrl=ws://[::1]:44386/extension/<uuid>

Expected behavior

The Windows Edge extension should be able to connect to the relay server started by playwright-cli in WSL2.

For this WSL2-to-Windows-Edge extension path, the relay URL should use an address reachable from Windows Edge, for example:

ws://127.0.0.1:<port>/extension/<uuid>

or the relay host should be configurable/normalized so Windows Edge does not receive ws://[::1]:<port>/... when that endpoint is not reachable across the WSL2/Windows boundary.

Actual behavior

The extension tab shows:

Failed to connect to MCP relay: Connection timeout

The failing connect.html URL contains:

mcpRelayUrl=ws://[::1]:<port>/extension/<uuid>

The same command succeeds when Node is forced to prefer IPv4 before starting the CLI:

export NODE_OPTIONS='--dns-result-order=ipv4first'

With that workaround, the generated connect.html URL contains:

mcpRelayUrl=ws://127.0.0.1:<port>/extension/<uuid>

and the extension reports that the client is connected.

Additional context

This appears distinct from #40557 / #40572. The installed CLI bundle already contains the executable path pass-through shape:

createExtensionBrowser(channel, executablePath, ...)
new CDPRelayServer(httpServer, channel, executablePath)

The issue appears to be the host emitted by the extension relay. In current source, extensionContextFactory.ts starts the relay server with:

await startHttpServer(httpServer, {});

and cdpRelay.ts serializes the bound server address via:

this._wsHost = addressToString(server.address(), { protocol: 'ws' });

On this WSL2 machine that produced [::1], which Windows Edge could not reach through the WSL2 localhost forwarding path. Forcing Node DNS result order to IPv4 produced 127.0.0.1 and fixed the connection.

Environment

System:
  OS: WSL2 Linux running on Windows 11
  Browser host: Windows Microsoft Edge

Binaries:
  Node: 26.2.0
  pnpm: global package manager

npmPackages:
  @playwright/cli: 0.1.13
  playwright-core: 1.61.0-alpha-1778188671000

Browser extension:
  Playwright Extension: 0.2.1