[Bug]: Windows snapshot/evaluate timeouts evict the shared server-browser host and abort another open #16921

Before submitting

• I searched existing reports, including [Bug]: A timed-out preview_evaluate keeps running in the renderer and makes all preview tools report "No preview automation host" until it finishes #16264, [Bug]: Preview loading bar never clears after a cross-origin iframe loads post-load, and automation timeouts drop the host #16779, [Bug]: windows desktop t3 browser codex models cant use anymore #12778, [Bug]: Environment browser stops at OpenAI Cloudflare verification while Edge works on the same Mac #16596, and [Bug]: Cloudflare Turnstile challenge loops indefinitely in the built-in browser preview #5002. This adds Windows .2735 ordinary-page evidence and a trace of one timeout aborting a separate open request. I am not claiming a newly established root cause for every symptom; please consolidate with an existing report if appropriate.
• I included the observed operation sequence, release commits, sanitized traces, successful retests, and limits of the investigation.

Area

apps/server / preview automation broker and server browser, with the Windows desktop/native-rendering path also involved.

Summary (original 7 October report)

On Windows 11, T3 browser snapshots and evaluations timed out after 15 seconds on example.com, even after recreating the tab and downgrading from .2774 to exact .2735. The timeout disconnected the shared automation host; the following click/status calls returned "No preview automation host is available".

During a later investigation, a snapshot already in flight timed out and disconnected server-browser, causing a different open request to fail after only about 6.5 seconds. The host registered again roughly one second later. This cascade is visible in the local traces and matches the broker implementation.

The original snapshot stall remains unexplained. The browser is intermittently usable: a later fresh .2735 tab, verified as Windows Chrome headless shell 154, successfully completed DOM reads, a snapshot, and a link click. Cloudflare verification remained blocked in that engine. Earlier Windows Cloudflare failure used native Electron/Chromium 152, so these should not be treated as a single proven engine-specific defect.

Latest live retest — 10 October 2026

Tested the unpatched official 0.0.46-nightly.20261010.2922 (bd2346eda). PR #16941 is still unmerged and was not installed. This tab actually ran on Windows Chrome headless shell 154.0.8037.92 (Chrome/154, Win32, navigator.webdriver === false), not the app's Electron 44.4.5 / embedded Chromium 152.0.7977.130 renderer.

The original ordinary-page 15-second snapshot failure and missing-host cascade were not reproduced in this retest. Current upstream's evaluation termination and response grace are present in this release. These successful normal typed-timeout paths do not establish recovery from a genuinely unanswered read/capture stage beyond the grace period or cancellation of expired queued/active work; those remain covered by PR #16941's code and regression tests.

Cloudflare verification remains unresolved in this fresh headless session. Initial 403 responses were observed at /cdn-cgi/zaraz/t; their relationship to verification failure is unknown, and the earlier origin-warning cause was not re-established. The page-change snapshot errors did not turn into a 15-second hang or host eviction. No challenge was solved, no credentials entered, and no sign-in attempted. Manual Take control, native Electron hidden capture and native macOS were not retested. The original evidence below remains historical evidence, not a claim that every symptom persists on nightly 2922.

Steps to reproduce

This is the recorded intermittent sequence; a later fresh headless tab succeeded.

1. On Windows T3 .2735, call preview_status, then preview_open and navigate to https://example.com.
2. Navigation succeeds, with title Example Domain and loading: false.
3. Call preview_snapshot({tabId, includeImage:false}). The recorded call times out after 15,000 ms.
4. Close that tab through t3_preview_close and open a fresh tab at the same URL with reuseExistingTab:false.
5. A small evaluation of document.title and the first link succeeds once.
6. Another snapshot times out after 15,000 ms. Evaluating body text and links then times out too.
7. The next click on the IANA link is rejected with the missing-host error. An immediate status call is rejected too.

The later cascade was captured while another snapshot was pending. A new preview_open request overlapped it and failed when that snapshot's deadline disconnected the shared host. This was not an open request reaching its own timeout.

Expected behavior

Successful navigation should leave ordinary page inspection and interaction usable. A slow snapshot or evaluation should not take out unrelated requests on a healthy shared in-process browser host. If a host is recovering, the error should describe that temporary state accurately.

Preserve the existing protection against replaying an action whose effects are uncertain. No automatic replay of clicks or other mutations is requested.

Actual behavior and trace evidence

All times are UTC on 7 October 2026; Amsterdam local time was UTC+2. Individual environment, thread, session, tab, and trace identifiers have been omitted.

The Windows app processes remained running. Process existence alone would not establish browser health, but the disconnection/re-registration sequence above is independently visible in server traces.

Relevant exact errors:

Preview automation snapshot timed out after 15000ms.
Preview automation evaluate timed out after 15000ms.
Preview automation client server-browser disconnected during open.

{
  "error": {
    "_tag": "PreviewAutomationTimeoutError",
    "operation": "snapshot",
    "failureCount": 1,
    "message": "Preview automation snapshot timed out after 15000ms."
  }
}

The subsequent click error, with the environment identifier replaced, was:

No preview automation host is available for click in environment [ENVIRONMENT_ID]. Preview tools run in a T3 Code desktop app that is open and connected to this environment; a headless server has no browser of its own. Do not retry. To check a page, use a headless browser from the shell, such as Playwright, or curl, or ask the user to open this thread in the T3 Code desktop app.

A corresponding for status error followed. No click was performed in that failed test.

Source findings and investigation limits

Release .2735 resolves to fd1c3386c4d60f3477ab3f13c87537848de099f5; .2774 resolves to 611132c171f3a821bd2e32f22261135cef6330ac.

1. Why other requests get disconnected is established. In PreviewAutomationBroker.ts, an unanswered primary request disconnects its connection. closeConnection fails the other pending requests on that connection. This explains the captured cascade, not the initial stall.
2. The existing recovery does run. ServerBrowser's host loop reconnects after one second; the traces agree. fix(preview): recover host registration after request timeouts #12535 is already merged. This is not simply the older permanently-unregistered-host problem.
3. includeImage:false does not bypass image capture. The MCP handler strips output-selection options. ServerBrowserPage.snapshot still waits concurrently for page evaluation, a boxed accessibility snapshot, and Page.captureScreenshot. The stalled branch has not been isolated. The accessibility timeout and broker deadline are both 15 seconds; whether a deadline race contributed here is unproven.
4. runtime:server does not identify the rendering engine. ServerBrowser's native-attachment path waits up to ten seconds for its desktop page and otherwise uses headless Chromium. The app's Electron version alone cannot identify a tab's engine.

Possible maintainer directions are to bound/diagnose individual snapshot stages, cancel or retire the affected operation/tab without evicting unrelated healthy work, and distinguish a recovering host from a genuinely absent one. These are suggestions, not an implemented or verified fix.

The latest release available when checked was .2787 (f570bd21663f56ce94c41829d3b7d72886e25a34). Its broker, server browser, snapshot implementation, and CDP relay files were byte-identical to .2735; its Electron host component differed. .2787 was not installed or tested, so no claim is made that upgrading cannot help.

Successful retest and remaining Cloudflare failure

At 19:45–19:47 UTC, without applying a source patch or another version change, a fresh Windows .2735 tab completed:

• DOM reads, including body textContent and innerText;
• a full snapshot, with accessibility refs and an internally captured PNG;
• a click using the snapshot-provided ref for Learn more, reaching the IANA example-domains page.

The tab reported runtime:server; its page user agent was:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/154.0.8037.92 Safari/537.36

navigator.webdriver was true. The Windows Chrome headless shell process and version were independently checked. This establishes recovery of basic automation on that engine; it does not identify why the original tab stalled or prove native Electron recovery.

Opening a fresh https://dash.cloudflare.com/login tab at 19:47:54 UTC still reached Just a moment.... At 19:48:24 it showed security verification, readyState:complete, no Sign in button, a 403 resource error, and No available adapters. warnings. At 19:51:42 it was still at security verification without a Sign in button. Snapshot inspection remained usable. No challenge was solved, credentials entered, identity altered, or session data transferred.

Cloudflare's supported-browser documentation describes limited support for embedded browsers and excludes automated browsers from production challenge solving. This provides compatibility context for the headless failure, not a diagnosis of the earlier native Electron failure.

Impact

Major degradation: the Cloudflare email-forwarding workflow could not be completed through T3's browser, and ordinary page automation also failed intermittently. A practical fallback eventually worked in an existing signed-in external Chrome session.

Version and environment

Earlier symptoms and all attempted workarounds

Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://challenges.cloudflare.com') does not match the recipient window's origin ('https://dash.cloudflare.com').

Related reports and proposed fixes

• [Bug]: A timed-out preview_evaluate keeps running in the renderer and makes all preview tools report "No preview automation host" until it finishes #16264 covers a timed-out evaluation continuing and temporarily making other preview tools unavailable. This report supplies ordinary-page Windows snapshot evidence and the pending-open cascade in the newer server-browser path.
• [Bug]: Preview loading bar never clears after a cross-origin iframe loads post-load, and automation timeouts drop the host #16779 reports .2735 loading/iframe issues and a timeout cascade on macOS. No injected iframe or stuck loading-bar trigger was established in this Example Domain test.
• [Bug]: windows desktop t3 browser codex models cant use anymore #12778 is an older Windows .0.0.42 missing-host report. Its metadata-timeout proposal fix(server): keep the preview host after an optional status timeout #14552 does not explain the recorded primary 15-second snapshot/evaluation deadlines; .2735 already avoids eviction for its optional metadata read.
• [Bug]: Cloudflare Turnstile challenge loops indefinitely in the built-in browser preview #5002 was the older native-preview Turnstile loop. Its native-user-agent fix fix(desktop): keep the native preview User-Agent so Turnstile passes #7110 is merged; the .2774 failure above already retained the native Electron user agent.
• [Bug]: Environment browser stops at OpenAI Cloudflare verification while Edge works on the same Mac #16596 reports a newer headless Cloudflare failure. Its proposed native-host synchronization fix fix(web): host local server browser tabs outside chat views #16620 was still unmerged when checked. It reports a successful anonymous login-page test on macOS, but has not been tested here and does not establish a fix for the earlier native Windows failure.
• fix(web): the desktop browser host answers every request that arrives together, not only the last #15965 addresses batched requests lost in the older web-client stream consumer. The .2735 preferred server browser consumes requests directly through Stream.runForEach; its applicability to these failures is unproven.

There is no verified complete fix from this investigation. Resolved sandbox startup, intermittent basic-automation recovery, a working external Chrome fallback, and upstream candidate fixes should be distinguished from a repaired T3 Cloudflare workflow.