Chrome 147 built-in remote debugging can hang connectOverCDP unless PW_CHROMIUM_ATTACH_TO_OTHER=1

[avivsinai]

Hi — sharing this in case it helps other dev-browser users. We needed this for yoetz to function when attaching to a user's real logged-in Chrome session on Chrome 147, and wanted to document the behavior plus the workaround we found.

Problem

When attaching dev-browser to a running Chrome 147 default-profile session using Chrome's built-in remote debugging flow (chrome://inspect/#remote-debugging), Playwright's connectOverCDP() can hang indefinitely.

In our testing, the attach succeeds at the transport/WebSocket level, but the browser never becomes usable through the normal Playwright auto-attach flow. This matches the upstream Playwright report here:

• microsoft/playwright#40027

Steps to reproduce

1. Open a normal signed-in Chrome 147 session on the default profile
2. Enable built-in remote debugging via chrome://inspect/#remote-debugging
3. Run dev-browser --connect against that Chrome session
4. Observe that the process can hang indefinitely during the Playwright attach path

What seems to be happening

The failure appears to be in the root browser-session auto-attach walk. Chrome 147 does not always emit the expected Target.attachedToTarget events for certain target types during that flow, so Playwright waits forever.

Workaround that fixed it for us

Setting this env var on the dev-browser process/daemon fixed the issue in our testing:

PW_CHROMIUM_ATTACH_TO_OTHER=1

This allows Playwright to treat targetInfo.type === "other" as attachable during the auto-attach walk. After setting it, the same Chrome 147 built-in remote-debugging session attached successfully.

Why this may belong in dev-browser

Right now we are injecting this env var from the consumer side when spawning dev-browser, but that is clearly a workaround/hack, not a proper product-level fix.

It seems cleaner if dev-browser handled this natively for the live-attach path, so all consumers benefit without needing to know about Playwright's hidden compatibility env vars.

Operational note

If the env var is added after a dev-browser daemon is already running, the existing daemon will keep the old environment. In practice, that means already-running daemons need one restart before the change takes effect.

If useful, I can turn this into a focused PR as well.