Built-in browser snapshots fail even after the desktop snapshot handler reports success

Summary

Screenshots intermittently stop working in T3’s built-in browser. The issue occurs across models and agent harnesses. The affected tab remains usable: DOM inspection, JavaScript evaluation, clicks, and navigation still work.

Investigation identified two failure modes:

1. Native capturePage() calls time out.
2. Native capture subsequently succeeds and the desktop snapshot handler reports success within milliseconds, but the requesting tool still times out after 15 seconds.

Other tabs can successfully return screenshots during the same session. Opening the preview with open: true does not reliably prevent or recover the failure.

Related: #3713, closed following #4685. That change bounded capture timeouts; this report also includes failures after the desktop handler reports success.

Environment

• T3 Code: 0.0.40
• macOS: 26.6.2 (25G83), arm64
• Electron: 43.4.1, according to the T3 v0.0.40 source
• Source inspected: v0.0.40, commit 09e8de9c655ae85410bf6b00446f272a01da81c7

Reproduction

Reproduced on a minimal page served over loopback HTTP: one button with an inline click handler that increments its text. No authentication, external resources, or application framework was involved.

The initial trigger is not yet deterministic. Some newly created tabs work; another failed on its first snapshot.

1. Open the page in a new tab using preview_open with open: true.
2. Call preview_snapshot.
3. Once a tab exhibits the failure, use preview_evaluate and preview_click to confirm that the page still responds.
4. Retry snapshots after opening the preview, resizing it, reloading, and navigating to another domain.
5. Start recording and retry a snapshot.
6. Create additional tabs and alternate snapshot requests between the affected and working tabs.

The affected tab continued to fail. Other tabs successfully returned screenshots, including one initially created with open: false.

Results

Operation	Observed result
DOM inspection and JavaScript evaluation	Worked on the affected tab
Clicking the counter	Worked; its text changed
open: true on the affected tab	Did not recover screenshots
Resize	Did not recover screenshots
Reload or navigation to another domain	Did not recover screenshots
Snapshot with includeImage: false	Still failed
Snapshots on other tabs in the same session	Succeeded repeatedly
Snapshot after starting recording	Desktop handler reported success, but the tool still timed out

In 0.0.40, includeImage: false still performs capture; it only omits the image from the final response.

Correlated logs

Failure mode 1: native capture timeout

Desktop traces show:

• automationSnapshot.capturePage
• PreviewOperationError / TimeoutError
• Approximately 3.25 seconds elapsed

This matches the implementation’s three capture attempts, each bounded by 1,000 ms, with 120 ms retry delays.

Failure mode 2: desktop success, followed by tool timeout

After recording was started, native capture on the affected tab began completing in approximately 4–6 ms. The desktop handler, including result encoding, also reported success.

One correlated example from 2026-09-11 at 07:52:23 UTC:

Trace operation	Outcome	Duration
desktop.ipc.method — desktop:preview-automation-snapshot	Success	13.63 ms
desktop.ipc.invoke — same operation	Success	13.68 ms
MCP preview_snapshot	PreviewAutomationTimeoutError	15,002.35 ms

This desktop-success/tool-timeout pattern occurred five times on the affected tab. Snapshot requests on other tabs succeeded during the same session.

The visible tool error was only:

Preview snapshot failed.

Diagnosis so far

The second failure cannot be explained solely by a native capture timeout: the desktop operation had already reported success.

The remaining unobserved section is the return path through the preload bridge and frontend automation request consumer to PreviewAutomationBroker.respond. Current traces do not establish whether the result fails to reach the frontend, fails during response dispatch, or reaches a broker that no longer accepts it.

The exact initial trigger and the exact point where the response stops progressing remain unconfirmed. Window visibility and background throttling have not been established as the cause.

Expected behavior and impact

A successful desktop snapshot should reach the requesting tool. A failed capture should produce a specific error and leave the tab able to recover on subsequent requests.

This breaks screenshot verification during long, unattended agent sessions: page interaction continues successfully while screenshots remain unavailable. The generic error also hides the distinction between a capture failure and a timeout after the desktop handler has already succeeded.

Start by tracing the snapshot response path from automationSnapshot.capturePage and the desktop:preview-automation-snapshot IPC operation through the preload bridge and frontend automation request consumer to PreviewAutomationBroker.respond. Use the correlated desktop-success/tool-timeout logs as the initial case. Done means successful snapshots reach the requesting tool, while capture failures return a specific error and later requests can recover.