Skip to content

[Bug]: Windows preview snapshots and remote viewing stall while T3 is completely covered #23139

Open
Open
[Bug]: Windows preview snapshots and remote viewing stall while T3 is completely covered#23139

Description

@genomez
genomez
opened on Oct 21, 2026

Environment

  • T3 Code: 0.1.2-nightly.20261021.3486
  • Host: Windows 11 x64
  • Remote viewer: Android app 2.0.0, build 350

Reproduction

  1. Maximize T3 Code.
  2. Maximize another application, such as Chrome, over it so T3 is completely covered.
  3. Have an agent open https://example.com using preview_open.
  4. Request preview_snapshot.
  5. Bring T3 back to the foreground and repeat the snapshot.

Actual behavior

While T3 is completely covered:

  • preview_open and preview_evaluate return promptly.
  • preview_snapshot consistently fails after approximately 10 seconds, reporting:
    "Preview automation snapshot timed out after 15000ms"
  • This happens both with and without includeImage.
  • One attempt also reported:
    "No preview automation host is available"
  • The Android viewer remains on "Connecting to browser".

Once T3 is brought to the foreground, the same tab's snapshot succeeds immediately and Android can view it.

Expected behavior

Agent snapshots and remote viewing should continue working when another application completely covers the Windows T3 window.

Checks already performed

The failure reproduced with:

  • Both Claude and Codex agents.
  • Default and Incognito browser profiles.
  • One tab and multiple tabs.
  • A Home Assistant login page and example.com.

This reproduction concerns a fully covered window, not necessarily a minimized window.

Related work

This adds a repeatable Windows covered/uncovered comparison. It does not establish that Chromium window occlusion is the sole cause, and none of the proposed fixes has been tested locally.

Activity

  1. juliusmarminge
    added
    needs more infoInitial triage showed no bug. Awaiting more info
    on Oct 22, 2026

  2. genomez commented on Oct 22, 2026

    @genomez
    genomez
    on Oct 22, 2026 – with ChatGPT Codex Connector
    Author

    Retest: still reproduces on Windows Nightly 0.1.2-nightly.20261021.3499 with Android 2.0.0 (build 362).

    This Windows build contains the main revision requested in triage.

    Used a fresh agent-owned Default-profile tab on https://example.com. T3 was fully covered by another maximized application (Codex Desktop), not minimized.

    Covered versus foreground

    State Operation Elapsed Result
    Covered preview_open 765 ms Succeeded
    Covered preview_evaluate 47 ms Succeeded
    Covered preview_snapshot, includeImage:false 16,014 ms Failed: Preview automation snapshot timed out after 15000ms
    Foreground, same tab preview_snapshot, includeImage:false 234 ms Succeeded

    While covered, the page reported visibilityState: "visible", hasFocus: true, and a 1280×800 viewport. A requestAnimationFrame callback fired after approximately 1 ms.

    Android viewing: stuck on “Connecting to browser” while T3 was covered. It recovered immediately when T3 was brought to the foreground, before the foreground snapshot was requested.

    One covered snapshot attempt and one foreground retry were performed. No settings changes, Chromium flags, restarts or installs occurred during the comparison.

    Sanitized trace excerpt

    October 21, 2026; local times, UTC−05:00. Table durations above are outer MCP tool-call spans; the excerpt below shows inner broker spans.

    20:37:21.110 → 20:37:37.116  16006 ms  PreviewAutomationBroker.awaitResponse  Failure: PreviewAutomationTimeoutError
20:37:37.115 → 20:37:37.116           PreviewAutomationBroker.disconnect / closeConnection
20:37:38.130                         PreviewAutomationBroker.connect / acquireConnection
20:39:56.856                         PreviewAutomationBroker.focusHost
20:39:57.054                         PreviewAutomationBroker.respond
20:40:08.947 → 20:40:09.179    231 ms  PreviewAutomationBroker.awaitResponse  Success

    T3 was brought to the foreground around 20:39:56. The respond at 20:39:57 had no agent request in flight, but we cannot correlate it to the earlier failed snapshot.

    The desktop trace contains tab/webview initialization spans, but no preview/capture spans during either snapshot attempt.

    Conclusion: the covered/foreground dependency is reproducible on this Windows build, and Android viewing recovers with foregrounding. These observations do not establish the underlying cause. The working rAF callback shows the page event loop was responsive; it does not establish that capture or streaming frames were available.

  3. juliusmarminge
    removed
    needs more infoInitial triage showed no bug. Awaiting more info
    on Oct 22, 2026

  4. WhiteWarrior625 commented on Oct 23, 2026

    @WhiteWarrior625
    WhiteWarrior625
    on Oct 23, 2026

    Note

    Posted by Claude Code (Opus 5.5) on behalf of the account owner.

    This also reproduces on a Linux host. The host user does not have to cover the window: the host desktop app draws every server-runtime tab of its primary environment (ElectronBrowserHost.tsx:33-40, rendersServerTabNatively in previewRuntime.ts:44-55). If nobody has that thread open on the host's own screen, the tab is never on screen there. That is always the case when the user works from another machine.

    The setup is the same as Comment A: a Linux desktop host on 3541 with a Windows desktop client.

    1. preview_open({url: "http://127.0.0.1:8741/page.html", open: false, reuseExistingTab: false}).
    2. Run preview_evaluate("({w: innerWidth, h: innerHeight, dpr: devicePixelRatio})"). It returns {w: 1280, h: 800, dpr: 1}, with a T3CodeNightly/...Electron user agent.
    3. Run preview_evaluate("new Promise(r => { const t = setTimeout(() => r('no rAF in 3s'), 3000); requestAnimationFrame(() => { clearTimeout(t); r('rAF ok'); }); })"). It returns "no rAF in 3s".
    4. preview_snapshot fails with Preview automation snapshot timed out after 15000ms. Running preview_navigate, preview_scroll and preview_evaluate on the same tab right afterwards works.
    5. Remote viewers of the tab get a stale or missing frame, because the screencast has nothing to send.

    The cause: when a tab is not on the host's screen, the inactive wrapper parks the guest at HIDDEN_BROWSER_WEBVIEW_OFFSET with visibility: hidden (hostedBrowserWebviewStyle.ts:66-74). keepPaintableWhenInactive is set only on macOS (HostedBrowserWebview.tsx:301). The only acquireActivity caller is recording (browserRecording.ts:537), so a remote viewer or an agent snapshot never keeps the guest painting. Event-loop stalls do not explain these timeouts: the host's event-loop-stalls.ndjson has no entry between 14:51Z and 15:19Z, when the timeouts happened, and today's largest stall is 2.8 s.

    #22743, which moves agent tabs into their own never-shown BrowserWindow, would cover agent-opened tabs. A tab the user opened and views remotely needs the same treatment, or an activity lease while any remote viewer is attached.

    See also #23936.

  5. latinrev commented on Oct 23, 2026

    @latinrev
    latinrev
    on Oct 23, 2026

    Confirmed on a Linux host with two minimize-and-restore cycles on 0.1.3-nightly.20261023.3579. This adds a newer-build Linux reproduction to the existing Linux report above.

    Host: Ubuntu 24.04.5 LTS, x86_64, GNOME 46, Wayland. The T3 desktop app runs the local server. Both desktop version and running serverVersion were verified as 0.1.3-nightly.20261023.3579, using the installed desktop package and /.well-known/t3/environment. The remote client is the Windows T3 desktop app.

    Each attempt used a fresh tab opened with:

    preview_open({url: "https://example.com", reuseExistingTab: false, open: true})

    On each returned tabId, we ran status, DOM evaluation, and one snapshot. On the host, the target thread was selected and its Browser panel open before the controlled comparison.

    Host state Snapshot mode Tool-call duration Result
    Unlocked, T3 foreground, target Browser panel open includeImage: true 167 ms Success
    Same thread and panel, T3 minimized includeImage: true 10,016 ms Timeout
    T3 still minimized, fresh tab includeImage: false 10,017 ms Timeout
    T3 restored to foreground includeImage: true 163 ms Success
    T3 minimized again includeImage: true 10,016 ms Timeout
    T3 restored again includeImage: true 137 ms Success

    DOM evaluation returned title: "Example Domain", readyState: "complete", and visibility: "visible" in every row. Opening the fresh tab did not restore the minimized host window.

    Both failed snapshot modes returned exactly:

    Preview snapshot failed: Preview automation snapshot timed out after 15000ms.

    Sanitized server trace excerpts, October 23, 2026, UTC:

    22:08:10.887899  PreviewAutomationBroker.awaitResponse  10002.574 ms  Failure
22:08:21.387384  PreviewAutomationBroker.awaitResponse  10005.948 ms  Failure
22:08:56.286658  PreviewAutomationBroker.awaitResponse  10002.125 ms  Failure

    Each retained the inner cause:

    The page was too busy to capture a snapshot in time. Wait for it to settle and take another snapshot.

    The installed ServerBrowserPage uses a 10,000 ms snapshot deadline, while the outer error reports 15,000 ms. The installed MCP handler removes includeImage before invoking snapshot capture, so includeImage: false does not bypass the screenshot operation.

    Limits: earlier exploratory attempts had not verified the host's selected thread and Browser panel, so they are excluded from the comparison above. Screen locking is disabled by host policy, so no valid locked-state test was possible. The user initially saw "Connecting" in both Windows inline and floating viewers, but viewer display after recovery and Windows mouse input were not verified. macOS was not tested. No capture settings, application files, or Chromium flags were changed, and T3 was not restarted. All test tabs were closed.

    This confirms a host-visibility dependency on Linux. It does not prove the exact Electron mechanism or that the full remote-viewing/input problem is fixed.

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

  6. achose369 commented on Oct 26, 2026

    @achose369
    achose369
    on Oct 26, 2026

    Additional related reproduction on Windows T3 Code (Beta) 0.1.2 (ProductVersion 0.1.2.0), observed on 2026-10-26. Posting here following the direction in the closure comment on #23261.

    The owner wanted to inspect their local AI/Game Overviews hub remotely through T3's collaborative browser, using the intended T3 Connect workflow:

    1. The agent opened http://127.0.0.1:41241/. T3 returned the expected Studio Hub title and /#/studio/overview URL, with available:true, loading:false, initially visible:false.
    2. Reopening the same tab with open:true, show:true returned visible:true, but the owner remained stuck on “Connecting” and could not inspect the hub.
    3. Status continued to report the expected page metadata. Two preview_snapshot attempts on the same tab failed with Preview automation snapshot timed out after 15000ms.
    4. Between attempts, an independent host-side HTTP request to the hub returned HTTP 200 with 1,927 bytes.

    Impact: the owner could not review the hub's features through the preview, and the agent could not obtain a snapshot. No successful human takeover, remote click, or recovery was confirmed.

    Limits: we did not record whether the host was locked, covered, minimized, or displaying another thread. The remote client/device and active route were not independently captured. We did not test preview_evaluate or observe an unavailable-host error in this reproduction. This is therefore related symptom evidence, not a confirmed reproduction of the same covered/locked-window cause. We have not tested a patched build or a local nightly.

    Detailed source review and comparison with #23261: #22465 (comment) . #23261 was closed as a duplicate, not as a verified fix. The earlier report also corrected locking from a claimed likely cause to an unconfirmed correlation.

    Posted by the owner's AI assistant with the owner's approval.

  7. is-Amir commented on Oct 26, 2026

    @is-Amir
    is-Amir
    on Oct 26, 2026

    Note

    Posted by Claude Code (Opus 5.5) on behalf of the account owner.

    Also reproduces on the stable channel: T3 Code (Beta) 0.1.2 (ProductVersion 0.1.2.0), Windows 11 Home 10.0.26200, Claude Code agent, Default profile, LinkedIn tab.

    From server.trace.ndjson, 2026-10-26 09:58–12:13 local: 55 PreviewAutomationBroker.invoke requests, 6 failures. Every failure hit the 10–15 s deadline. Most were Preview automation snapshot timed out after 15000ms, but clicks fail the same way: Preview automation click timed out after 15000ms. So the stall isn't limited to snapshot capture.

    From desktop.trace.ndjson, 2026-10-23 to 2026-10-26: 32 failures of PreviewManager.initializeControlSession, reached through restoreControlSession after recoverDetachedControlSession (about 64 detach/recover cycles):

    PreviewOperationError: Desktop preview operation failed: initializeDebugger.defaultBackground (WebContents N)

    It happened on at least 7 different WebContents IDs. I haven't confirmed it has the same cause as the covered-window stall, but it happens on the same tabs and in the same sessions.

    In the 0.1.2 desktop bundle, the main window calls webContents.setBackgroundThrottling(true) on first reveal. Throttling is only lifted while a frame-capture session (recording or picture-in-picture) is active, so plain agent automation runs throttled whenever the window is covered. That matches #22743's approach of keeping agent tabs unthrottled while T3 is hidden.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions