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

Environment

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

Reproduction

Maximize T3 Code.
Maximize another application, such as Chrome, over it so T3 is completely covered.
Have an agent open https://example.com using preview_open.
Request preview_snapshot.
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

fix(desktop): agent preview tabs keep working while T3 is hidden #22743: proposed desktop background-tab hosting fix.
fix(server): text-only browser snapshots no longer hang on hidden tabs #21494: proposed fix for text-only snapshots unnecessarily waiting for screenshots.
preview_snapshot on a background tab never returns and blocks every later action on that tab #16567: earlier background-snapshot report. Its closing maintainer comment acknowledged remaining background-capture failures and requested a focused new issue.

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.

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.

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.

preview_open({url: "http://127.0.0.1:8741/page.html", open: false, reuseExistingTab: false}).
Run preview_evaluate("({w: innerWidth, h: innerHeight, dpr: devicePixelRatio})"). It returns {w: 1280, h: 800, dpr: 1}, with a T3CodeNightly/...Electron user agent.
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".
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.
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.

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.

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:

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.
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.
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.
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.

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.

Retested on Windows T3 Code Nightly 0.1.6-nightly.20261030.3940, with another window fully covering T3. The previously reported problem did not reproduce.

Using an existing Wikipedia tab:

Call	Result	Approximate elapsed time
`preview_evaluate` — title and URL	Success	0.24 s
`preview_snapshot` without an image	Success	0.61 s
`preview_snapshot` with an image	Success	1.46 s

The screenshot rendered the article correctly at 1281×800. There were no errors, retries or recovery actions. During the covered-window test, Android viewing and control also worked: tapping, typing, navigation and scrolling.

The agent did not navigate, resize or bring T3 forward during these calls. The user confirmed that T3 remained fully covered. Timings were measured around the calls and include tool overhead.

For comparison, the October 21 test consistently timed out on snapshots while T3 was fully covered, and Android remained on “Connecting to browser.”

Limitations: this is one successful retest on this Windows/Android setup. It does not identify which change resolved the symptom or establish behavior when minimized, locked or on other platforms. The page’s visibility flag reported visible; that flag alone does not establish native Windows occlusion.

Note

Posted by Claude Code (Opus 5.5) on behalf of Jakob.

Still reproduces on T3 Code (Nightly) 0.1.8.0, Windows 11 Enterprise 10.0.26200, Claude Code agent, Default profile, including the fully covered case reported as fixed on 0.1.6 above. It also happens when T3 is minimized or the Windows session is locked (user working from another computer through T3 remote).

preview_snapshot fails with "Preview automation snapshot timed out after 15000ms", and preview_navigate times out. preview_status sometimes reports "No preview automation host is available … reconnecting".
preview_open and preview_status still return a URL and title, and the page's HTTP requests do reach the server, so the page loads but nothing is captured.
Restoring, uncovering or unlocking makes it work again immediately.
Observation: while T3 stays completely covered, the preview does update whenever the covering window is moved, even though T3 is still fully hidden. So frames only seem to be produced when Windows sends a repaint or window-position event; otherwise the hidden window isn't composited.

Tried launching T3 with --disable-features=CalculateNativeWinOcclusion --disable-backgrounding-occluded-windows --disable-renderer-backgrounding. The switches reached all Chromium processes, but snapshots then timed out even with T3 visible and the session unlocked. Restarting without them restored normal behaviour, so these switches aren't a workaround.

The macOS locked-screen fix in #27092 (native webContents.capturePage instead of CDP Page.captureScreenshot) suggests the same approach may be needed on Windows.

Note

🤖 Claude Opus 5.5 responding on behalf of Elliot

Another repro on Windows 11 desktop, with the user away from the machine (window likely minimized or covered):

preview_open on https://example.com (both open:false and open:true) succeeds, but status keeps reporting visible:false.
Every preview_snapshot fails with Preview automation snapshot timed out after 15000ms. Two parallel child agents hit the same thing on localhost dev servers.

From the source at e455200077, the snapshot always awaits CDP Page.captureScreenshot, even with includeImage:false (McpHttpServer.ts decodes the PNG before deciding whether to return it). The accessibility tree is fetched separately but can't come back without the screenshot. That fits the frame starvation the desktop host already documents for offscreen guests (DesktopBrowserHost.ts). A stalled earlier capture can also hold the per-tab capture lock before the snapshot's internal deadline starts.

Possible directions: validate #32415 on Windows with a covered/minimized window; let text-only snapshots skip image capture (as #21494 proposed); bound the lock wait (#24523); report the stage that stalled (#24130). Related: #23015, #23936, #23022.

Data from macOS, and a smaller fix on a branch. #22743 takes a different route, so I'd like a maintainer's direction before opening a PR.

On the desktop side, two causes add up. I found them with Electron 44.10.1 harnesses that copy T3's webview stack.

The main window turns background throttling on at its first reveal (DesktopWindow.ts, revealWhenReady). While a screenshot is pending, the client moves the hidden guest from its -100000 resting place into the viewport. But a covered, minimized or hidden window commits no frames, so the move never reaches the compositor.
The capturing guest sits at z-index -1, behind the app (hostedBrowserWebviewStyle.ts). html and body are opaque, so the guest is fully covered, and Chromium does not draw a fully covered guest.

The fix on the branch:

While a server tab's capture or recording is pending, the desktop turns throttling off for the main window, and back on when the last one ends. This uses the lock that startFrameCapture and stopFrameCapture already use, and one predicate decides every re-throttle.
The capturing guest is drawn above the app, clipped to its top-left pixel, at opacity 0.99 and without pointer events. CDP still captures the guest's full-size surface.

Harness results on macOS. The page colour changes before each capture, so stale frames do not count.

Tab created while the window was on screen, then the window covered, minimized or hidden: 5/5 single screenshots, 4/4 two-tab pairs, and 2/2 screenshots taken while another tab records, in each state.
Tab created after the window was already off screen, the row that fix(desktop): agent preview tabs keep working while T3 is hidden #22743's table marks "never". One fresh launch per state, 3 rounds per variant. The states were app hidden, window hidden, minimized, and covered by another app's window.
- This fix: 12/12 fresh, full-size screenshots in 9-51 ms.
- Main's placement: 0/12, still pending at 3 s.
- With fix(desktop): preview snapshots no longer stall on Chromium's legacy capture path #32415's CDPScreenshotNewSurface switched on, the same: this fix 12/12, main 0/12. The flag alone does not help here.
Live, in a dev desktop build with the window covered by another app: 3/3 full screenshots, against 0/9 on the old build.

Trade-offs:

While a capture or recording is active, one page pixel shows at the window's top-left on Windows, Linux and macOS fullscreen.
While the window is off screen, the main renderer runs unthrottled for the capture.
A hidden tab keeps all its desktop tools: DevTools, the element picker and desktop recording.

Not tested: Windows, the platform of this report; Linux; a locked screen (#27092 covers locked macOS); and display sleep. Bounded snapshots (#23936) would cover display sleep.

Branch: main...Entrpi:t3code:fix/desktop-preview-occluded-capture

Related: #22743 hosts each agent tab in a never-shown BrowserWindow. That is robust, but agent tabs lose DevTools, the element picker and desktop recording. #27092 keeps macOS guests at (0,0) behind the app and captures through capturePage(stayHidden). I can share the harness.

Would you take this smaller change, or is #22743 the direction?

Note

Posted by Claude Code (Fable 5.2) on behalf of the account owner.

Another macOS data point, plus a workaround that needs no rebuild.

Setup: macOS 26.6.2, desktop Nightly 0.1.9-nightly.20261110.4478 (Electron 44.10.1) hosting the server. The viewer is the iOS app over T3 Connect.

Observed on the live app, through the main window's DevTools protocol:

When the app is hidden, the main page's visibilityState turns hidden and requestAnimationFrame stops.
A capture request still flips the tab's wrapper to data-preview-rendering="active" at left: 0, z-index: -1. The snapshot then waits until the window is shown again.
A guest that was already at (0,0) before the app was hidden answered Page.captureScreenshot in 26 ms while hidden. A guest still parked at -100000 px timed out.

Harness (Electron 44.10.1): with the main window throttled and the app hidden, the capture never answers. Calling setBackgroundThrottling(false) on the main window first makes it answer in about 15 ms. This matches cause 1 in Entrpi's comment above.

Workaround without a rebuild: start the app with --remote-debugging-port and send Emulation.setFocusEmulationEnabled {enabled: true} to the main window's page while a capture is pending. The page keeps drawing while hidden. The cost is that document.hasFocus() reads true, so it should be released when the capture ends.

Linking #33719, which doesn't reference this issue. It fixes the same hang by another route.

Cause 2 above (guest covered by the app): fix(desktop): capture covered preview surfaces without hanging #33719 copies the guest's surface with Electron's webContents.capturePage(), with a 5 s deadline. A covered guest is captured without being drawn above the app. For screenshots, that does the job of the z-order half of my branch.
Cause 1 (window off screen): fix(desktop): capture covered preview surfaces without hanging #33719 does not change this. A hidden or minimized main window commits no frames, so the guest never leaves its -100000 resting place. The live-app data in the comment above shows this, and setBackgroundThrottling(false) fixes it there. I have not tested whether capturePage answers in that state.

If you take #33719, the throttling half of my branch is the part still needed: throttling stays off for the main window while a capture or recording is pending. I can cut the branch down to that change.

Follow-up to my last comment. I tested #33719 while the T3 window is off screen. Its capturePage() copy does not answer then. Turning throttling off while a tab paints fixes that.

Harness: Electron 44.10.1 on macOS, with T3's webview stack and #33719's capture loop. The loop calls capturePage() every 50 ms and gives up after 5 s. The guest uses main's placement, behind the app. Each window state ran 9 rounds:

5 single screenshots;
2 pairs of screenshots taken together;
2 screenshots of one tab while the other tab streams a screencast.

A capture passes when it is full size and shows the colour set on the page just before it.

Window state	#33719	#33719 plus the throttling change
Covered by another app	4/9	9/9
Minimized	0/9	9/9
Window hidden	0/9	9/9
App hidden	0/9	9/9

The covered rounds with #33719 passed only before macOS marked the window hidden. In every failure, capturePage() never returned, so #33719 reported "did not paint within 5 seconds". The screencasts sent 0 frames. With the change, captures took 9-93 ms and screencasts ran at about 60 frames per second.

Dev desktop app, with the window covered and one hidden tab, driven by a scripted agent turn:

fix(desktop): capture covered preview surfaces without hanging #33719 alone: both preview_snapshot calls failed with "Preview automation snapshot timed out after 15000ms". preview_recording_start failed with "The preview tab did not paint within 5 seconds."
With the change: both snapshots had a 1280x800 screenshot, in under 100 ms. The recording's mp4 shows the navigation from Page B to Page C.

The change: one commit on top of #33719: Entrpi@794f84a9fc

It changes only Manager.ts. The main window stays unthrottled while a hidden tab paints for a capture. This uses the same lock that recordings and picture-in-picture already use for throttling.
The z-order half of my earlier branch is not needed with fix(desktop): capture covered preview surfaces without hanging #33719, so no page pixel shows on screen during a capture.
The existing Manager test now fails without the change.

Should this go into #33719, or come as a separate PR after #33719 merges?

Additional Windows confirmation on T3 Code Nightly 0.1.8-nightly.20261108.4353, using the installed desktop app as the host.

Environment: Windows 10 Pro 10.0.19044, Radeon RX550/550 Series, driver 31.0.21923.11000. The PC stayed awake throughout the tests.

Controlled tests on the same browser tab:

With the main T3 window visible and foregrounded, preview_snapshot succeeds.
Minimizing the main window causes preview_snapshot to time out. This reproduced repeatedly, including on an about:blank page containing only a heading and button in a fresh Incognito profile.
Fully covering the maximized T3 window with an opaque test window also causes the timeout. The test window was confirmed to remain present after the timeout; T3 itself was not minimized in this case.
Restoring/uncovering T3 allows a subsequent snapshot of the same tab to succeed, without restarting the app or recreating the tab. Restoring it while a capture is already pending did not reliably rescue that particular request.

preview_evaluate still reads the loaded page while the host is minimized. Failed snapshots finish after roughly 10 seconds but report:

Preview automation snapshot timed out after 15000ms.

Resource sampling during the tests did not show RAM/VRAM exhaustion or sustained CPU saturation, and the GPU process remained alive. This supports the host-window visibility trigger rather than a page-specific or resource-exhaustion explanation.

I have not tested #33719, the additional throttling change discussed above, or a newer Nightly binary on Windows. This is confirmation of the existing failure, not validation of a proposed fix.

Diagnostics were performed with Codex through T3 Code's built-in browser tools.

Linux / Hyprland data point (Omarchy, Hyprland 0.56.2, kernel 7.2.15; T3 desktop AppImage built 31 Oct 2026, v0.1.9), Claude Code agent

T3 window	preview_snapshot
On the visible workspace	works
Fully covered by another window on the same workspace	works (unlike the Windows reports)
Another T3 thread in front	works
A background tab opened with `open:false`, window on screen	works
Switched to another Hyprland workspace (T3 on no monitor)	times out after 15 s, every call

While it's off screen, preview_evaluate keeps working and reports visibilityState: "visible", hasFocus(): true, which fits the "off-screen window commits no frames" cause described above. On Hyprland, covering alone doesn't stop frames; only an off-screen workspace does.

Two related things on a smaller screen (1440x900):

Captures can't be taller than the window: a 1440x2400 viewport comes back cut off at about 1,100 CSS px.
After moving the window to that screen, the page picked up a zoom of about 0.913 that Ctrl+0 didn't clear and that came back on later loads.

Workaround I'm using: headless Chromium + Playwright for screenshot passes; T3's preview for interactive work.

Same stall on macOS when the screen is locked, not only when the window is covered on Windows.

Desktop-rendered preview tabs depend on the desktop window painting. With the T3 desktop app running and attached, setUpTab in apps/server/src/preview/ServerBrowser.ts connects the tab to the desktop webview (desktopRenders → connectDesktop). It marks a tab headless only when the desktop does not attach within DESKTOP_ATTACH_TIMEOUT (10 s). Once the Mac locks, the webview stops producing screencast frames, and captureViewport gets no answer. Remote viewers and agent snapshots stall even though the page itself is loaded and navigable.

Symptom

macOS 26.6.2 (arm64), T3 Code desktop 0.1.9, iOS app as the viewer. Screen locked (CGSSessionScreenIsLocked = true).

preview_open <public https page>   -> available: true, page loaded
preview_snapshot                   -> Preview automation snapshot timed out after 15000ms.
iOS viewer                         -> black canvas, spinner, "Connecting to browser..."

After the screen was unlocked, without any other change, the same tab's preview_snapshot returned at once, and the iOS viewer streamed.

Not fixed. This is a report from a user setup, with no branch.

Suggested direction: when the desktop reports that it cannot paint (screen locked, display asleep, window fully occluded), move the tab to the headless server browser, or render new tabs headless in that state. The phone and the agent could then keep working while the Mac is unattended. A user setting to always run agent-opened tabs headless would also cover this. Separately, a viewer whose first frame never arrives should end in an error with a reason ("the host's screen is locked"), not stay on "Connecting to browser...". #24852 covered the still-capture timeout, but this viewer never left the spinner.

Navigation Menu

Repository navigation

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

Environment

Reproduction

Actual behavior

Expected behavior

Checks already performed

Related work

Covered versus foreground

Sanitized trace excerpt

Symptom

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Environment

Reproduction

Actual behavior

Expected behavior

Checks already performed

Related work

Activity

genomez commented on Oct 22, 2026

Covered versus foreground

Sanitized trace excerpt

WhiteWarrior625 commented on Oct 23, 2026

latinrev commented on Oct 23, 2026

achose369 commented on Oct 26, 2026

is-Amir commented on Oct 26, 2026

genomez commented on Oct 30, 2026

JakobAV commented on Nov 6, 2026

ElliotDrel commented on Nov 7, 2026

Entrpi commented on Nov 8, 2026

hunterbohm commented on Nov 10, 2026

Entrpi commented on Nov 11, 2026

Entrpi commented on Nov 11, 2026

metasirony commented on Nov 11, 2026

RohitKaushal7 commented on Nov 12, 2026

felix-enobleon commented on Nov 14, 2026

Symptom

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions