Playwright Report: One Unresponsive Tab Can Stall a CDP Attach

A Playwright issue opened on September 15, 2026 reports that connectOverCDP can fail to complete when a browser already contains one page target that no longer answers page-level Chrome DevTools Protocol commands. In the supplied reproducer, the WebSocket connection succeeds and browser-level commands still respond, but the overall attach waits until its explicit timeout.

The report is new, open and has no maintainer comments or confirmed fix at review time. Its root-cause analysis and workaround are the reporter’s findings, not a project conclusion. The described case does not require a proxy and does not show that Playwright, Chromium or remote browser services generally fail.

Source note: Microsoft Playwright issue 42730, “connectOverCDP never completes when a pre-existing page target stops answering CDP commands,” opened September 15, 2026; open with zero comments at review time.

What the reproducer shows

The report uses playwright-core 1.63.0-alpha, packaged with Playwright CLI 0.1.18 and 0.1.19, and Microsoft Edge 148 on openSUSE Tumbleweed. The author starts a browser with remote debugging, suspends one renderer process, then calls connectOverCDP with a 15-second timeout.

According to the issue, the call log reaches “WebSocket connected” but does not return a browser object. Resuming the renderer lets the same attach finish in about 31 milliseconds. In a three-tab comparison, browser-level target enumeration and the two responsive tabs continue working while the suspended tab’s page-level command does not answer.

That distinction matters: transport connectivity can be healthy while initialization of one pre-existing target remains blocked.

The reported wait boundary

The issue author traces the wait to Playwright auto-attaching to existing targets and waiting for all corresponding pages to initialize or report an error. For the suspended target, several page-level CDP commands are reportedly sent without receiving replies, so the initialization promise does not settle.

This is a plausible explanation backed by the supplied reproducer, but it has not yet been confirmed by a maintainer. Operators should preserve the raw command-and-response timeline rather than labeling every stalled attach as this issue.

The report also distinguishes this case from an earlier first-navigation-commit change and from prerender activation behavior. Similar symptoms can have different wait points.

Why proxy browser fleets should care

Teams often reach remote browsers through a proxy, gateway or hosted debugging endpoint. When attach stalls after the WebSocket connects, a generic “proxy timeout” label can send the investigation in the wrong direction.

Separate these layers:

1. proxy DNS and TCP connection;
2. proxy-side TLS and authentication;
3. tunnel establishment;
4. CDP WebSocket upgrade;
5. browser-level CDP response;
6. target enumeration and auto-attach;
7. page-level initialization for every existing target;
8. workload navigation and data collection.

A healthy result at one layer does not clear the next. Conversely, one unresponsive page target does not prove that the proxy route or browser process is unavailable.

Build a target-level diagnostic matrix

Use only browsers and pages you are authorized to inspect. Give every connect attempt a bounded timeout and record timestamps for the WebSocket upgrade, first browser-level response, target enumeration, page-session attachment and initialization completion.

For each target, capture a non-sensitive identifier, type, URL category, creation age, lifecycle state and whether a minimal approved command received a reply. Do not log full private URLs, cookies, authorization headers, page content or customer identifiers.

Compare four controlled cases:

• a new clean browser with one blank page;
• the same browser with several responsive pages;
• a test renderer deliberately paused in an isolated lab;
• the production-like browser after the suspect target is safely removed or restarted.

The expected evidence is a per-target command timeline, not just a single connect duration.

Define liveness beyond the WebSocket

A remote browser worker should not become ready merely because its debugging socket accepts a connection. Require at least:

• a successful browser-level command;
• target enumeration within a budget;
• initialization or explicit isolation of every required page;
• a lightweight page-level response;
• a controlled navigation through the approved proxy path;
• confirmation that the observed exit and session match the assignment.

The Playwright headless stall liveness report provides a broader active-probe framework. For transport-level reuse failures, compare the Playwright keep-alive ECONNRESET report.

Contain one bad target without hiding it

If an owned automation worker repeatedly times out during attach, stop assigning new work and quarantine the worker. Preserve a sanitized target inventory and bounded trace, then restart the affected page or browser through your approved orchestration path.

Do not close, reload or alter tabs in a user-controlled browser without explicit authority. A forceful recovery that destroys unsaved work is not an acceptable health check.

The issue author describes a local workaround that races initialization with a timeout and drops certain target entries, but explicitly says it is not a proposed fix. Skipping an unresponsive page can restore capacity while also hiding a real failure. Track the skipped target, reason and recovery action, and do not count the worker as fully healthy until the intended workload passes.

Use the proxy concurrency saturation test before scaling recovered workers; repeated attaches can amplify pressure on an already unhealthy browser pool.

Operations checklist

• Set an explicit attach timeout; never allow an unbounded queue.
• Distinguish WebSocket, browser-level and page-level readiness.
• Pair sent and answered CDP command identifiers in sanitized traces.
• Record the first target that misses its response budget.
• Quarantine a failing worker before retrying it.
• Keep a clean-browser control in the same network path.
• Confirm that proxy routing remains correct after recovery.
• Review trace fields for URLs, tokens, cookies and customer data.
• Test supported stable versions before treating an alpha report as a fleet-wide regression.
• Recheck the upstream issue for maintainer confirmation or a supported fix.

FAQ

Does this report prove a proxy caused the attach timeout?

No. The reproducer requires no proxy. It shows why a successful network connection does not guarantee that every existing page target can initialize.

Is “WebSocket connected” enough to mark a worker ready?

No. It confirms one transport boundary. Browser-level and page-level probes are still required.

Should operators automatically skip every slow tab?

No. Skipping may discard required state or hide a failure. Use a bounded, documented isolation policy only for owned automation targets, preserve evidence and verify the intended workload afterward.

Compliance note

Inspect and control only browsers, pages, proxy accounts and destinations you own or are explicitly authorized to operate. Minimize diagnostic data, protect credentials and browsing state, respect destination terms and rate limits, and never disrupt a user’s tabs or unsaved work for automated recovery.