Browser preview snapshots time out after pairing with an isolated dev client#28136

Related improvements: merged #23489 adds bounded reasons to preview timeout reporting (and target diagnostics for clicks); open #24130 reports the actual snapshot deadline and pending capture stages. Open #28154 enables navigation away from a page whose script never yields. None establishes why this reported page stalled; the actual root cause remains unproven and this issue should remain open.

seeing the same Preview automation snapshot timed out after 15000ms here, but without any pairing or isolated dev client. just the desktop app on macOS (nightly channel, now on 0.1.7-nightly.20261103.4119 / cefb544af3c9) driving normal local vite/next dev servers

pulled numbers from my agent logs (last 60 days):

• 162 of 940 preview_snapshot calls timed out, every one at exactly 15000ms
• it clustered hard: oct 22 was 55 of 120 snapshots, oct 23 was 28 of 34
• since oct 26 it's basically gone, 4 of ~264
• not just screenshots: 130 timeouts were with includeImage: true, 32 were text-only

once a tab started timing out it usually kept going (runs of up to 14 in a row), so it looked more like the tab got stuck than a slow page. in the worst thread the agent gave up and switched to a headless browser

so something in the nightlies around oct 25/26 seems to have fixed it for my setup. might be worth checking if that's the same fix for the post-pairing case

I independently reproduced the snapshot symptom during an isolated Windows client pass. This is actual tool behavior, not a fault-injected busy renderer:

• A fresh owned incognito tab on the local pairing form times out repeatedly in preview_snapshot({includeImage:false, save:false}), returning PreviewAutomationTimeoutError, operation snapshot, message Preview automation snapshot timed out after 15000ms.
• After pairing through the form, two serial snapshots of the stopped draft page return the same error.
• A separate local fixture containing only a button and an idle paragraph also returns the same snapshot timeout. Its finite busy-loop button was never activated.
• preview_evaluate of document.body?.innerText succeeds on both pages after failed snapshots. Native click/type/Enter successfully complete the pairing form. The simple fixture still reports idle.

The owned tab reports available, not loading, and agent-controlled. preview_open(open:true) still reports visible:false; the page itself reports document.visibilityState === "visible" and focus. That is an observation, not proof that visibility is the cause.

Host user-agent reports T3CodeBeta/0.1.6, Electron/44.10.0, Chrome/152.0.7977.169 on Windows. The local app under test is current main 9e85538535 plus the existing #30544 ACP fix (integration e80019e767); that app SHA is not a claim about the installed tool-host source.

This differs from the original three-stopped-thread fixture and demonstrates the broader responsive-page snapshot symptom, not its root cause. Normal DOM evaluation has not reproduced #28139. Local read-only log excerpts were retained, but no correlated CDP capture/reply boundary has yet established which stage stalls. No production fix is proposed from these observations.

Additional responsive-page evidence from the same isolated Windows pass: preview_act timed out clicking the existing Settings button with a CSS selector (15000 ms), and clicking the Grok radio option with a locator (3000 ms). preview_evaluate immediately read the page successfully and dispatching a DOM click activated each intended control. These are observations about the automation interaction path, not evidence of a hung renderer or the snapshot root cause. No browser system was switched.

Read-only installed package metadata identifies the tool host as commit 2359643cffa6, version 0.1.6; the separate dev app remains integration e80019e767. A request-correlated capture trace is still needed to isolate the snapshot stage.