preview_snapshot on a background tab never returns and blocks every later action on that tab#16567

Triage

Confirmed: a background desktop tab's snapshot never settles, and every later action on that tab waits behind it. The controlled split in the report matches current main (9503155da67a). Nightly 0.0.46-nightly.20261006.2735 (fd1c3386c4) is an ancestor, and these files are unchanged since that tag. Nightly 20261005.2702 does not contain #15328.

What the code does

On the desktop app, every tab of the local server is a <webview> the server drives over CDP (ServerBrowser.ts desktopRenders / connectDesktop). ElectronBrowserHost mounts a webview for every server tab, including reveal: false. open: false does not add a right-panel surface (ChatView.tsx, hiddenTabIds), so the guest stays inactive.

An inactive guest is parked at -100000,-100000. On macOS it keeps visibility: visible so Electron 43 does not blank it, but it is still fully outside the window. hostedBrowserWebviewStyle.ts already says Electron does not composite that guest. Recordings avoid this by marking the surface rendering-active and placing it at 0,0 behind the app. A background agent tab does not.

preview_snapshot always takes a full snapshot, including when includeImage is false (handlers.ts). ServerBrowserPage.snapshot runs page.evaluate, ariaSnapshot (15s timeout), and captureViewport together. captureViewport sends a bare Page.captureScreenshot with no timeout. DOM reads can finish while the screenshot waits for a frame the offscreen guest never presents, so the combined promise does not settle at 15s.

That snapshot runs on the tab's SessionControl queue, which has no per-action timeout. The broker gives snapshot 15s, then returns PreviewAutomationTimeoutError and disconnects the host. The in-flight capture is a tryPromise on a forked handler, so the disconnect does not cancel it. The server host is preferred: true and reconnects, which matches the trace. The next call on that tab waits behind the same capture.

preview_open with open: true reveals the tab inside that same queue, so a reveal issued after a stuck snapshot never starts. An open on the preferred host gets the 660s budget meant for a Chromium install (PreviewAutomationBroker.ts). preview_status and t3_preview_close skip the queue. close does not abort the capture; destroying the webview is what lets CDP settle, which is why the queued calls answer in the same second as the close.

visible is tab.viewers.size > 0 in both reportLiveTabs and preview_status. Viewers are screencast subscribers only. A desktop <webview> never adds one, so a desktop-rendered tab stays visible: false after open: true.

Likely causes (ranked)

1. Uncapped screenshot of an offscreen desktop guest, still holding the tab queue. This is the failure the traces show: open: true snapshots in tens of milliseconds, open: false hits 15000ms every time, status stays instant, and a later reveal hangs until close. Headless server tabs do not use this webview placement.

2. The broker timeout and the tab queue are different clocks. The 15s error is real, and so is the later work. Evicting the host does not free the tab.

Related, not duplicates

• #15328 moved agent snapshots onto this server CDP path. That is the regression boundary versus nightly 2702.
• #13600 (open) bounds and refreshes capturePage in apps/desktop/src/preview/Manager.ts for hidden or occluded windows. Agent snapshots no longer go through that function. Merging it does not cap Page.captureScreenshot here and does not unblock SessionControl.
• #3713 (closed) was the same symptom on the old desktop host, which retried capturePage at 1s times 3.
• #16264 and #12898 are the evaluate and wait_for host-eviction cases. Neither operation ran in this report.

Next step

Bound Page.captureScreenshot the way desktop capturePage is bounded, and make a broker timeout stop counting as the tab's current action so a later open: true can reveal the guest. A background snapshot also needs a frame from a guest that is not on screen. The offscreen placement is why recordings force the guest inside the window.

The visible: false report is a separate bug in the same status payload. It can stay on this issue.

Helpful follow-up

None. The version, the open: true / open: false split, and the trace are enough.

Reproduced with a standalone local demo: Electron 44.4.2, macOS arm64.

• Before: DOM read completes in 0.2 ms; offscreen Page.captureScreenshot remains pending after 15 seconds, blocking the next queued action.
• Experimental repair: temporarily render the guest behind the app, capture natively with a deadline, then restore its position. 5/5 captures in 33–42 ms, preserving draft, session and document state.

Run npm ci, then env -u ELECTRON_RUN_AS_NODE npm start. Fresh disposable profile; local synthetic page only.

This isolates the Electron capture mechanism with a simple Promise queue. Full T3/provider/MCP integration remains unverified. It complements #16941's timeout recovery.

Same on macOS 26.7.1 arm64, Nightly 0.0.46-nightly.20261008.2833, Claude Code thread. The tab reported visible: false. Times are UTC, 2026-10-09.

• 09:01:29: preview_snapshot timed out after 15 s on a heavy React Flow canvas page.
• Every later preview_evaluate on that tab timed out at 15 s: 9 calls over 22 minutes, from 09:01:56 to 09:22:54. preview_status still answered immediately.
• The tab's renderer process stayed alive with the same pid and normal memory (120–260 MB in renderer-history.ndjson), so it wasn't a crash.
• t3_preview_close at 09:23:18 released it, and a new tab worked.

Earlier the same morning, snapshot timeouts at 08:26, 08:41 and 08:48 were each followed by timeouts on that tab's next calls.

[!NOTE] 🤖 gpt-6.1-sol responding on behalf of Benedikt

Adding post-fix evidence from 0.0.46-nightly.20261010.2935, desktop app with a local server on macOS (darwin arm64 25.5.0). Triage CLI Node: 26.8.2.

The user frequently sees Preview automation snapshot timed out after 15000ms while a different thread is selected in T3 Code.

These four snapshot timeouts occurred with #17693 already included. Their stack traces reference binCli-DBAO6Yxt.mjs; the matching installed app bundle identifies itself as .2935 and contains the 1,000 ms host-response grace added by that fix.

From server.trace.ndjson, 2026-10-10. Times are UTC and identify span starts:

At approximately 16:29:01 UTC, an in-flight open and an in-flight navigate also failed with PreviewAutomationClientDisconnectedError: Preview automation client server-browser disconnected during open/navigate.

At release commit 98beed1a226c42b85c52ff5ee9d5dbb67d776a77, ServerBrowserPage.snapshot still awaits page evaluation, the accessibility snapshot, and captureViewport concurrently. The latter sends Page.captureScreenshot without its own deadline. This is consistent with the mechanism discussed here, but the stalled stage was not isolated on this machine, and thread visibility at these exact timestamps was not recorded. No fresh controlled foreground/background reproduction or fix was performed during this triage.

Investigated by Codex (GPT-6.1 Sol) via t3 triage.

Additional reproduction on Linux with T3 Code nightly 20261011.2967, using the Codex harness (gpt-6.1-sol). No login is required for the page in this reproduction.

Steps observed

1. preview_open({url:"https://www.wikipedia.org", profileId:"default", reuseExistingTab:false, open:false})
2. Open returns successfully with title Wikipedia, loading:false, visible:false, and agent ownership.
3. preview_snapshot({tabId:<returned tabId>, includeImage:false})
4. Snapshot fails after approximately 16,017 ms with:

Structured error:

A subsequent navigation attempt reported:

Immediately afterwards, preview_status({tabId}) still returned available:true, Wikipedia metadata, and loading:false. Closing the diagnostic tab through t3_preview_close succeeded.

Earlier in this same app session, a fresh background Example Domain tab snapshotted successfully in 168 ms, so the failure appears intermittent in this environment. We have not established its root cause or verified the proposed workaround. includeImage:false did not avoid this failure. No changes were made to T3 code or configuration.

Follow-up after a full PC restart: the issue still reproduces. preview_status initially reported no attached tab; opening a fresh background https://www.wikipedia.org tab in the default profile succeeded (title: Wikipedia, loading:false), but preview_snapshot({tabId, includeImage:false}) again failed after ~16,017 ms with Preview automation snapshot timed out after 15000ms. This suggests the timeout persists across a PC restart and on a public page without authentication.

Still reproduces on the v0.1.0 stable release (81493efb71e8), Windows 11 (10.0.26200), desktop app with local server, Claude agent provider. Triage CLI 0.0.45; the bug happened on server 0.1.0.

Sequence (2026-10-16, UTC)

1. preview_open({url:"http://localhost:8765/", open:false, reuseExistingTab:false}) → ok, visible:false.
2. preview_resize({mode:"freeform", width:1280, height:800}) → ok.
3. preview_hover (selector, then role locator) → Preview automation hover timed out after 15000ms (2 of 2). preview_snapshot({includeImage:false}) → Preview automation snapshot timed out after 15000ms. The broker disconnected and reconnected the host about 1 s later.
4. preview_open({tabId, open:true}) → hung ~2.5 min until the turn was interrupted. The panel showed the "No preview yet" empty state.
5. The user opened the browser panel manually, then the agent opened a fresh tab with open:true. preview_snapshot, preview_hover and preview_evaluate all worked. preview_evaluate reported dpr:1, inner:[1280,800].
6. On that working tab, preview_resize freeform 800×500 returned setting 800×500 but viewport 1280×800, and the next preview_snapshot timed out again.
7. t3_preview_close released both tabs. Renderer history shows no webview crash or restart throughout.

What the v0.1.0 source shows

• HostedBrowserWebview.tsx:300-307 sets keepPaintableWhenInactive: isMacPlatform(...). On Windows and Linux an inactive guest gets visibility:hidden and the −100000 offset (hostedBrowserWebviewStyle.ts:64-74). Automation never raises backgroundActivity, so the guest stops compositing. Page.captureScreenshot and Playwright's stability-based hover then never settle, while Runtime.evaluate still works. This matches the open-panel vs closed-panel split above.
• The stuck operation keeps holding the tab's SessionControl queue after the broker times out, so the reveal from open:true (ServerBrowser.ts around :1837-1858) queues behind it with the 660 s preferred-host budget.
• Related, same session: the saved snapshot was 640×400 for a 1280×800 DPR-1 viewport. ServerBrowserPage.ts:187 applies RENDER_SCALE = 2, but desktop tabs skip the DPR override (see #16690). visible stays false for desktop-drawn tabs even when they are on screen (see #17015).

Workaround that worked: open the thread's browser panel before the agent's browser actions, use open:true, and close and reopen the tab after the first timeout rather than retrying.

Investigated and written with T3 Code triage, Claude Code (Claude Opus 5.5).

this issue basically makes the inapp preview completely unusable. I did come up with a workaround tho by adding a snippet in my global AGENTS.md (or CLAUDE.md)

This is still a lot of time and tokens wasted... hopefully this can be addressed soon :D

Additional reproduction on signed macOS arm64 Nightly 0.1.1-nightly.20261016.3203, source commit e3b35d1b2440b104f0bc2e357377c348121234dd.

In the running desktop app, a selected desktop-rendered tab snapshotted in 122 ms. After selecting another desktop tab, snapshotting the first returned Preview automation snapshot timed out after 15000ms. A subsequent evaluation also timed out. Closing the stuck diagnostic tab released queued work without restarting T3.

A separate Electron 44.4.5 fixture isolates the capture mechanism, without agent instructions or user data:

• Guest at -100000,-100000, visible and background throttling disabled: Page.captureScreenshot remained pending beyond the fixture's four-second observation deadline.
• Runtime.evaluate still returned in 0-1 ms.
• Moving the same guest to 0,0 behind the app released the outstanding capture in 15 ms.
• Moving it offscreen again reproduced the stall; restoring it released capture in 13-18 ms.
• captureBeyondViewport and fromSurface variants did not bypass the stall.

An experimental patch uses an acknowledged renderer paint lease and bounded snapshot/recovery handling. Adapter-level Electron integration captured hidden tabs and recovered after a deliberately missing acknowledgement in the same process. The exact-base port passed 133 focused tests and desktop/server/web typechecks.

Limits: full packaged-application verification is incomplete. The patch was not installed over the signed app, and these results do not establish production readiness. A local replacement cannot retain the vendor's Touch ID keychain signing association, so the desired delivery is an official signed update. This report does not conflate separate Codex native-pipe or malformed-tool-call errors with the Preview capture stall.

Still reproducible on macOS arm64, T3 Code desktop with local server 0.1.1-nightly.20261018.3315, commit 9c161462c94f7d9d6d9169da5c841457cbadf213. Triage CLI: 0.1.0.

The saved local diagnostic run on 18 October used a static seven-element page with no scripts, animations, external resources, or authentication. This follow-up verified its persisted tool results against server traces and release source; it did not rerun the browser tests.

• First background tab: snapshot timed out in 10,046 ms; DOM evaluation succeeded in 38 ms. Revealing the same tab with preview_open({tabId, open:true, show:true}) made its next snapshot succeed in 96 ms.
• Second fresh background tab: snapshot timed out in 10,089 ms. Revealing it made capture succeed in 121 ms; three further snapshots passed.
• A fresh tab opened with open:true passed its first snapshot in 231 ms.

Both static-page failures used includeImage:false and reported Preview automation snapshot timed out after 15000ms. The source has a 10-second inner capture deadline, while the broker constructs the message using its 15-second default. Screenshot capture still runs with includeImage:false.

The hidden-tab/reveal trigger is confirmed here. The individual stalled CDP command was not instrumented. This does not establish the cause of every timeout across all chats.

Diagnostic tabs and the fixture server were cleaned up. The user added scoped agent instructions to reveal tabs before capture and prefer DOM evaluation when an image is unnecessary. No application patch was applied.

Investigated and drafted by Codex, GPT-6.1 Sol, via t3 triage.

Additional Windows reproduction on Windows 11 Pro 10.0.26300 x64, T3 Code 0.1.1-nightly.20261018.3302, installed commit d0918f1659f4, Electron 44.4.5.

The background-capture failure remains reproducible in this nightly. An audit of one project's history found 47 actual snapshot-tool failures across 18 threads. This excludes messages quoting the error and inherited duplicate activity. That historical count does not establish that every timeout had the same cause.

Fresh minimal reproduction, using a local static HTTP page containing only a heading and a button:

The fresh background tab's snapshot returned after 10,038 ms with:

A blank background tab also reproduced the failure in 10,042 ms. JavaScript evaluation still worked on the failing tab. This probe returned false on the failing tab and true on a working control tab:

Both documents reported document.visibilityState === "visible". Disabling the returned image did not bypass capture. The roughly ten-second observed deadline and fifteen-second error message are separate; this report does not establish an indefinitely blocked action queue in this newer nightly.

An independent, disposable-profile native Electron 44.4.5 Windows fixture used a real <webview> and the production resolveHostedBrowserWebviewWrapperStyle helper from 9a43c64ec0ef69d57efe96e3635527f085f80b1e. The parent window used show: false, offscreen: true, and backgroundThrottling: false. With the guest hidden at -100000,-100000, the animation-frame probe expired. Applying the helper's existing rendering-active layout at 0,0 behind the app enabled animation frames and a real CDP PNG capture:

This was one successful isolated native run, not a latency benchmark or full packaged-app verification. The fixture's parent-window configuration differs from the normal desktop window. Individual CDP stages of the live failure were not instrumented. The synthetic page and frame-production comparison support the offscreen-compositing explanation, but do not prove the cause of all historical failures.

This evidence complements the existing work in #21534. I have not checked out or run that PR's head on Windows, so these observations must not be counted as Windows validation of its implementation. The running installed application was not replaced or restarted.

Investigated and drafted with GPT-6.1-Sol through the Codex harness in T3 Code.

Additional controlled macOS reproduction using the unmodified production layout helper from 70d60e03a7a35c6fa131825bbfa05ec893e69912 (installed signed Nightly 0.1.1-nightly.20261017.3238). This isolates the capture mechanism from project pages and T3 user settings.

• macOS 26.3.1 arm64, Electron 44.4.5, Chromium 152.0.7977.130; GPU compositing enabled.
• Separate Electron process and fresh temporary profile, static data: page with only a heading and button; no network, authentication, extensions or copied T3 state. Parent window visible and unfocused.
• resolveHostedBrowserWebviewWrapperStyle({active:false, renderingActive:false, keepPaintableWhenInactive:true, ...}) gives the stock macOS wrapper at left/top=-100000, visibility:visible.
• Runtime.evaluate succeeds; the page reports document.visibilityState === "visible".
• A real Page.captureScreenshot({format:"png"}) is still pending at the fixture's 2-second observation deadline.
• Changing only to the same helper's existing renderingActive:true layout (left/top=0, behind the opaque host overlay) releases that same pending capture: PNG 15,684 bytes, 2,044 ms total from the original request. A subsequent CDP screenshot also succeeds. No native-capture substitution or source patch is involved in this comparison.

This is a compositor/layout fixture, not a new full packaged-app reproduction or an indefinite-hang claim. Current preview_* probes in this thread succeed and report Chrome 154, unlike the Electron Chromium 152 runtime above; I am not counting those as proof that the desktop guest path recovered. Latest official Nightly 0.1.1-nightly.20261019.3360 was inspected for the layout helper but not installed or run. No claim of testing #21534's implementation.

The installed signed app and its update channel remain untouched. The desired fix is an official signed Nightly update; this report does not require users to install a local fork. This supports the existing issue rather than a separate project/configuration bug.

Investigated with GPT-6.1-Sol through the Codex harness in T3 Code.

Confirmed on T3 Code 0.1.0 stable, Linux/Omarchy, on 19 October 2026. Adding to this existing issue after reading the contribution guide and bug template and searching for duplicates.

Environment

• Installed app metadata: t3code version 0.1.0; Arch package t3code-bin 0.1.0-1.
• Omarchy 4.0.5 (Arch-based), Linux 7.2.8-9-omarchy, x86_64, Hyprland/Wayland.
• Codex harness, GPT-6.1 Sol, built-in T3 preview_* tools.
• The failing background tab initially reported T3CodeBeta/0.1.0 Chrome/152.0.7977.130 Electron/44.4.5 in navigator.userAgent.

Fresh reproduction

1. preview_status({}) reported no attached tab.
2. preview_open({open:false, reuseExistingTab:false}) created a fresh background tab.
3. preview_evaluate({tabId, expression:"({answer:1+1,href:location.href,ready:document.readyState,userAgent:navigator.userAgent})"}) succeeded: answer:2, href:"about:blank", ready:"complete", Electron user agent above.
4. preview_open({tabId, url:"https://example.com", open:false}) succeeded with title Example Domain, loading:false, and agent ownership.
5. preview_snapshot({tabId, includeImage:false}) failed with Preview automation snapshot timed out after 15000ms.
6. preview_status({tabId}) still succeeded immediately, reporting available:true, loading:false, visible:false, and agent ownership.
7. Even preview_evaluate({tabId, expression:"({href:location.href,ready:document.readyState,title:document.title})"}) then failed with Preview automation evaluate timed out after 15000ms.
8. t3_preview_close({tabId}) succeeded. No local Playwright/Chromium fallback was launched during this reproduction.

Expected: snapshot completes or fails recoverably; a subsequent trivial DOM read remains usable. Actual: snapshot timeout followed by evaluation timeout while status still reports an available loaded tab.

Sanitized evidence

Recorded tool completion times and durations from today's provider log; times below are UTC, tab identifiers omitted:

Snapshot structured error:

Today's earlier saved tool results independently show repeated snapshot timeouts at 10:49, 10:50, 10:54, 13:04, 14:03, 14:42 and 14:48 UTC, plus evaluation timeouts. These historical failures were not individually root-caused. User impact is major degradation/frequent failure: the user has been instructing agents to skip browser use.

Control, workaround and limits

After closing the failed diagnostic tab, a new preview_open({url:"https://example.com/?t3-preview-control=visible",open:true,reuseExistingTab:false}) succeeded; its snapshot completed in 68 ms (recorded tool duration), and a later DOM read succeeded. That later DOM read reported Chrome/154.0.0.0 without Electron, so this is not a controlled same-runtime proof that open:true fixes the desktop guest path. Host/runtime selection changed during the investigation. Both diagnostic tabs were closed afterward.

This confirms the timeout and subsequent loss of automation on stable 0.1.0, without project code or authentication being required. It does not establish which internal CDP stage stalled, prove an indefinitely blocked queue, or validate any proposed fix/newer nightly. No installed app, system settings, or browser configuration was modified. Separate historical Chromium fallback crashes under the agent sandbox are not being presented as the cause of this built-in preview failure. Raw logs are omitted because they contain unrelated private workspace information.

Still happening in the signed macOS arm64 desktop app on Nightly 0.1.1-nightly.20261019.3348 (88d104a35f70), 19 October 2026 UTC.

A real preview_snapshot returned in about 10.0–10.1s. The tool error was Preview automation snapshot timed out after 15000ms. The server span kept the cause: The page was too busy to capture a snapshot in time. That matches the 10s tooBusy() deadline in ServerBrowserPage, with the broker printing its 15s budget. The host did answer, so this sample is the capture deadline rather than the broker dropping the host.

Nightly 0.1.1-nightly.20261019.3360 (1451e7cb2303) is 17 commits after 3348, and none of them are #21534. Updating to that nightly does not include the fix. I have not run 21534's head.

Reproduced a closely matching snapshot failure on macOS 26.5 arm64 in 0.1.1-nightly.20261020.3411, October 20. Adding a minimal app-independent reproduction on a newer build.

Minimal reproduction

1. Serve a static page on loopback with no external resources, authentication, scripts, media or iframes. The entire page can be:

   html

   1	<!doctype html><title>Second diagnostic page</title><h1>Second page</h1>

2. Open a fresh agent-owned incognito tab with preview_open({open:false,reuseExistingTab:false,profileId:"incognito"}) and retain its tab ID.

3. Navigate that explicit tab to the local page using preview_navigate.

4. Evaluate ({title:document.title,text:document.body.innerText,visibility:document.visibilityState}) on the same tab. This succeeds with the expected title/text and visibility:"visible".

5. Call preview_snapshot({tabId,includeImage:false}). This times out. A fresh snapshot attempt on a richer local counter page had the same failure; one retry returned a browser-disconnected error.

Observed raw errors:

Discriminating checks

• Navigation and simple evaluation continue to work.
• A requestAnimationFrame callback fires before a 750 ms fallback on the static page. This does not support a general renderer/animation-frame freeze; it does not rule out a hidden-webview screenshot problem.
• preview_open({tabId,open:true}) returns, but the reported preview visibility remains false and a following snapshot still fails. I did not establish that the page was physically visible, so this is not a controlled visible-tab counterexample to the original report.
• A separate Chromium browser automation backend reads the local counter-page DOM in approximately 0.09 s; its Increment button changes the counter from 0 to 1.
• Snapshot failure spans in the server trace last approximately 10,003 ms, while the surfaced error says 15,000 ms. The internal cause is The page was too busy to capture a snapshot in time. A one-heading fixture makes that message misleading as a diagnosis of application load.

Source observations and limits

Reference source was fetched and inspected at d36b7da2485bc889b320a285deea181f637d760a; the installed ASAR was also inspected read-only for the relevant snapshot implementation. That reference commit is not claimed to be the installed build's exact revision.

The snapshot path combines password-masking readers, DOM evaluation, PNG capture and accessibility-tree capture under one overall deadline. Even includeImage:false still enters internal screenshot capture. There is no stage-specific attribution in the returned failure. The exact stalled await is not isolated; screenshot capture remains a candidate, not a proven cause.

The broker's response-deadline eviction is distinct from an inner snapshot timeout; not every snapshot error proves shared-host eviction. Related host-cascade evidence exists in #16921.

Suggested next diagnostic step: record bounded per-stage timings and determine which CDP/read operation remains pending; consider a text-only path that genuinely skips PNG capture, and test recovery without disrupting other tabs.

No app patch or restart was performed. The diagnostic tabs and loopback server were closed after the test. No project contents, credentials, private URLs or raw session logs are included here.

More macOS data that fits this issue. It comes from agent logs from 2026-10-07 to 10-09, not a live retest.

Environment. macOS 26.6.2 (Darwin 25.6), arm64, T3 Code Nightly desktop app (0.0.46 nightlies; desktop traces show 0.0.46-nightly.20261008.2813 to 0.0.46-nightly.20261009.2873 for 10-08 onward), Codex agents, local dev pages on loopback plus a few external https pages.

Counts. 20 timeouts on simple operations out of about 1,500 preview calls: 9 snapshot, 5 evaluate, 2 resize, 2 open, 2 navigate. 16 of the 20 took exactly 15 s. Errors:

Why I think it is this issue.

• preview_status reported visible: false before almost every call. Only 2 calls in the whole window had visible: true. So nearly all automation ran on hidden or background tabs. One exception: the 2026-10-09 13:48 case was opened with open: true (an external https page), and its snapshot and evaluate still timed out.
• Trivial evaluates such as ({title: document.title, url: location.href}) timed out right after a snapshot timeout on the same tab. That matches your diagnosis that later actions wait behind the stuck snapshot in the tab queue. This is an inference from call order. The desktop traces for these builds have no automation spans.
• Between timeouts, preview_status answered at once with loading: false, the URL, and the title.

Example sequence (UTC, 2026-10-08).

1. preview_open {open: false, reuseExistingTab: false} and then preview_navigate to a loopback page. Both completed.
2. 07:01:14: preview_snapshot timed out after 15 s.
3. 07:01:47: preview_evaluate of document.title timed out after 15 s.
4. 07:10:49: preview_status showed the tab with loading: false and its title.
5. 07:14:18: preview_resize timed out after 15 s.

Other times: 2026-10-07 01:39:01 and 01:39:27 (two snapshots after a completed navigate to a loopback fixture page), 06:24:35, 17:13:34, 19:42:28; 2026-10-09 00:12:35 and 13:48:05.

Each of these timeouts also evicted the host, as tracked in #16921. The follow-up calls failed with "No preview automation host … Do not retry."

Small ask. An earlier comment here notes that the server span kept the cause ("The page was too busy to capture a snapshot in time."). The agent only sees timed out after 15000ms. Putting that cause, or the stage reached, into the tool error would let agents tell a busy page from a wedged tab queue.

Additional macOS arm64 evidence from October 21, including an isolated causal experiment on the installed app's exact Electron runtime.

Installed app / live failure

• T3 Code 0.1.1-nightly.20261020.3411, declared commit d36b7da2485b; Electron 44.4.5, Chromium 152.0.7977.130, Node 24.21.0.
• A fresh blank preview after a backend restart failed in 10,009 ms with Preview automation snapshot timed out after 15000ms. A separate example.com tab also failed. DOM evaluation and requestAnimationFrame probes worked; earlier stage tracing completed the accessibility tree in approximately 100 ms but left screenshot work pending.
• open: true did not repair the observed failure. The returned visible: false is not evidence of the physical window's state.

Isolated native experiment, without T3, its CDP relay, Playwright, or the agent harness

Using an official Electron 44.4.5 executable, a static real webview, and a separate temporary profile:

1. With the guest at (-100000, -100000), background throttling disabled, and document.visibilityState === "visible", DOM reads worked but Page.captureScreenshot stayed pending beyond the 1,500 ms observation bound.
2. Moving that same guest to (0, 0) behind an opaque application element released the same pending CDP request, returning a nonempty 1280x960 PNG. Total elapsed time was 1,632 ms, including the deliberate offscreen wait. A sampled green pixel identified guest content rather than the opaque white cover.
3. A later capture under the cover could still stall; a native webContents.capturePage() call drove completion of the pending CDP screenshot.
4. Offscreen again, both CDP screenshot and native capture exceeded the bounded probes. Moving inside and requesting a native copy released them.

The same sequence reproduced on Electron 44.9.0 / Chromium 152.0.7977.167. These observations support both paintable guest placement and native compositor copies; they do not support a longer timeout or an Electron patch upgrade alone as a fix.

Fix experiment and limits

Our independently implemented #22547 uses the same underlying approach as #21534: renderer activity preparation plus bounded serial native copies, returning the original CDP result. An isolated Electron 44.4.5 fixture using our production capture helper, renderer activity module, React, and the existing production style resolver returned three fresh green/purple/blue PNGs in 146 / 28 / 32 ms. Pixels changed as requested; each operation released its activity count to zero and restored the offscreen position.

This last fixture bypasses Manager/relay wiring and showed its own inactive window. It is not installed-app acceptance, hidden-window acceptance, a test of #21534's head, a reliability benchmark, or proof of unchanged Page Visibility behavior. The installed T3 app was not modified. We discovered #21534 after opening our PR and are comparing/adapting useful differences rather than presenting the two PRs as unrelated fixes.

Follow-up after adapting parts of #21534: a second Electron 44.4.5 fixture kept its host window hidden throughout and left guest background throttling enabled. It returned fresh green/purple/blue 1280x960 CDP PNGs in 37 / 29 / 32 ms, again releasing activity to zero and restoring the offscreen position. Host visibility remained false and guest throttling remained true. The guest nevertheless reported document.visibilityState === "visible" after capture; no unchanged-visibility guarantee follows from stayHidden or from these observations. This remains a helper/React/style fixture, not full Manager/relay or packaged-app acceptance.

Investigated with GPT-6.1-Sol through the Codex harness in T3 Code.

Reproduced on Windows on 0.1.1-nightly.20261020.3411 (d36b7da2485b), the same build as the macOS repro above. Windows 11 Pro 10.0.26200 x64, desktop app with local server, Claude agent provider. Triage CLI 0.0.45; the server version comes from /.well-known/t3/environment.

Setup. A Claude agent thread ran a long build and delegated subtasks with delegate_task. The parent and the subtask threads all used preview tools while I was viewing other threads. Every tab was desktop-backed and reported visible:false.

Counts from the provider event logs (one parent thread and two delegate_task subtask threads):

• Parent thread: 3 of 3 preview_snapshot calls timed out at 15s. The other preview calls in the thread succeeded, including preview_evaluate.
• Subtask A: 4 snapshot timeouts, 4 preview_navigate timeouts (one at 15s, three at 60s), 2 preview_evaluate timeouts at 15s, 1 preview_click timeout at 15s. 92 other preview calls succeeded.
• Subtask B: 1 snapshot timeout, and 1 preview_click with timeoutMs: 2000 that timed out after 20000ms.

Differences from the original report:

• preview_open({tabId, open:true}) returned in under a second right after a snapshot timeout. It did not hang. The next snapshot on that tab still timed out.
• In the server trace, one failed snapshot span lasted 10010ms, which matches SNAPSHOT_TIMEOUT_MS = 10_000 (ServerBrowserPage.ts:201). Another lasted 16004ms, which matches the broker's 15s plus 1s grace. So both timeout paths fire, and both surface as "timed out after 15000ms".

Docs mismatch. The preview_open tool description says "Set open=false for background-only automation" (apps/server/src/mcp/toolkits/preview/tools.ts:77). On desktop, nothing keeps an off-screen agent tab painting, so agents follow that advice and lose snapshot, click and navigate. Until #22547 or #21534 lands, it may be worth changing that wording so agents don't pick open:false on desktop.

Investigated with t3 triage by Claude Opus 5.5 (claude-opus-5-5) running in Claude Code.

Additional Linux desktop reproduction on 21 October 2026: Ubuntu 26.04.1 LTS, x86_64, T3 Code AppImage with its local server and a Codex agent. The live server identifies itself as 0.1.1-nightly.20261020.3438 via /.well-known/t3/environment (verified independently of the downloaded AppImage filename).

Controlled fresh-tab comparison

All tests used https://example.com/ and explicit returned tab IDs:

1. preview_open({url:"https://example.com",open:false,reuseExistingTab:false,profileId:"incognito"}) succeeded and reported loading:false, title Example Domain.
2. preview_snapshot({tabId,includeImage:false}) failed with Preview automation snapshot timed out after 15000ms. The same failure also occurred on a default-profile background tab. On that default tab, a subsequent preview_evaluate reading document.title, document.readyState and body text succeeded immediately, with readyState:"complete".
3. A fresh incognito tab opened with preview_open({url:"https://example.com",open:true,show:true,reuseExistingTab:false,profileId:"incognito"}) produced a successful snapshot, including the accessibility tree and 1280×800 screenshot metadata.
4. A further fresh incognito tab opened with open:false timed out again on snapshot.
5. All four diagnostic tabs closed successfully through t3_preview_close.

The open:true,show:true call still returned visible:false; the successful snapshot is the observation here, not proof of physical window visibility. Opening a fresh tab with those flags was a working workaround in this run, not an established universal fix.

Four inspected PreviewAutomationBroker.awaitResponse failure spans lasted approximately 10,001–10,003 ms, despite the surfaced 15,000 ms message. This matches the reporting discrepancy noted above; it does not by itself establish broker eviction or identify the stalled capture stage.

AppArmor ruled out as the remaining startup blocker

This host initially had a separate Ubuntu AppArmor sandbox failure. The official t3 browser setup installed the T3 browser exception while leaving the global restriction enabled. Afterward, HTML preview rendered and executed JavaScript successfully, and the bundled headless browser loaded the page with its sandbox enabled. The background-tab snapshot failures and the fresh-tab comparison above occurred after that repair.

No application code was modified. The specific internal await responsible for these Linux failures was not isolated, so screenshot/compositor capture remains a hypothesis for this run. This adds Linux/newer-build evidence to the existing macOS and Windows reports.

Investigated with GPT-6.1-Sol through the Codex harness in T3 Code.

Thanks for the report. One part of this is fixed on main in #20446. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: Background-tab snapshots can still time out because the underlying screenshot capture remains unbounded. If that part still matters to you, please open a new issue for that part only.