[Bug]: Preview tabs can't be seen from mobile and all automation times out (Windows desktop unattended)#23015

This also happens on macOS, with a desktop client instead of a phone.

Setup: The host is the macOS desktop app on 0.1.3-nightly.20261023.3579; the desktop app runs the server itself. The client is the macOS desktop app on a second Mac, connected via T3 Connect.

What happens:

• An agent opens a tab in a thread that isn't open in the host's window, because nobody is at the host.
• The client's preview pane stays on "Connecting to browser…" forever. preview_snapshot times out, while preview_evaluate works.
• When the same thread is opened on the host, new tabs connect immediately.
• Tabs whose screenshot already hung never recover, even once the thread is on screen. Only new tabs work.

Why, from the source (commit 5bb54a0f):

1. A tab of a thread that isn't on screen sits at (-100000, -100000). Electron doesn't composite it (apps/web/src/browser/hostedBrowserWebviewStyle.ts:51-74), so Page.captureScreenshot and Page.startScreencast never produce a frame. JS keeps running; requestAnimationFrame still ticks.
2. attachViewer waits for startScreencast(1), then for pushStill (apps/server/src/preview/ServerBrowser.ts:2408-2410), before it returns the viewer's stream. pushStill → captureViewport has no timeout (:2346-2355). The viewer is therefore never wired up, and the client shows "Connecting…".
3. The desktop host runs one screenshot per tab at a time (apps/desktop/src/preview/DesktopBrowserHost.ts:101-123), and the slot has no timeout. A capture that never returns blocks every later screenshot of that tab: viewer stills and agent snapshots alike. That explains why the old tabs stayed broken after the thread was opened.
4. Since #19919, the desktop app also hosts tabs for threads that aren't open. So this now hits every agent tab whenever the user isn't at the host. That covers the "unattended" cases here and in #23139 / #23936.

It isn't the network or T3 Connect: the remote client reaches the server fine (navigation, reload and preview_evaluate work). The cause is that the desktop app draws the tab while the remote client is the one viewing it.

Fixes: #24133 and #22877 both take a background-activity lease around agent screenshots. That should fix point 2's initial still. I left a note on #24133 about the live stream. Points 2 and 3 would also be safer with a timeout, so one lost capture can't block a tab permanently.

Workaround meanwhile: keep the thread open on the host and open a fresh tab. Or run T3 as a standalone server (t3 serve) so tabs use headless Chrome.

Additional observation on Windows with a remote T3 Connect client (collected 2026-10-27; posted by Codex on behalf of the account owner).

Environment: Windows 11 Enterprise build 26200, T3 Code desktop executable 0.1.2 / server 0.1.2, x64. The owner connected from another device through T3 Connect; the remote device OS/client type was not recorded. Whether this thread was visible in the host desktop window was not checked.

Observed:

• The remote conversation remained usable. The owner saw the preview pane stuck on Connecting..., including after a fresh tab was opened.
• preview_open / preview_navigate reported the local Node.js application's title and loading: false; a later status reported the tab visible. That metadata did not mean the owner could see it.
• preview_snapshot returned Preview automation snapshot timed out after 15000ms. and preview_evaluate returned Preview automation evaluate timed out after 15000ms. The snapshot error recurred in a later check.
• An independent headless browser on the host rendered the local application's overview and project list. This is a local control; it does not test T3 preview streaming. Remote interaction was not verified.

Sanitized server trace excerpts (UTC):

The 15,000 ms value is the reported automation deadline; the approximately 16-second values above are measured enclosing trace durations. The broker reconnect events describe the preview automation host, not a demonstrated interruption of the T3 Connect conversation.

Limits: This resembles the report here and the broker sequence in #16921. It does not establish the cause of the initial stall or prove that the stream and automation failures share a cause. We did not restart the app, change the connection, test with the host thread foregrounded, or test the standalone-server workaround. No raw logs, credentials, pairing links or private application data are included.

Same issue here on 2026-10-29. Windows 11 Pro (build 26300), Claude Code harness, following the thread from my phone. preview_open on http://localhost:4817/ (a local static server) first returned "visible": false with url chrome-error://chromewebdata/. That was a race: the server wasn't up yet. Calling it again loaded the page and reported the correct title with "visible": true. preview_resize (freeform 1440×900) succeeded but reported a viewport of 1280×800. preview_snapshot with includeImage: true failed with Preview automation snapshot timed out after 15000ms. On retry, the call was interrupted with no result. Workaround: close the tab and take screenshots with headless Edge (msedge --headless=new --screenshot).

So it isn't limited to SSO or external pages. Snapshots of a plain localhost page also time out when the user is on mobile.

Possibly the same problem, on the latest nightly: the desktop tab hangs for a phone viewer, and running the server without the desktop app avoids it. The cause of the unanswered tab is not established, so this may or may not share a root cause with this issue.

Environment

• Host: Windows 10 Pro (build 19045) x64, T3 Code (Nightly) desktop app, server 0.1.7-nightly.20261101.4016
• Viewer: Xiaomi 15, Android app t3code-android-internal-2.2.0-739.apk, from the 0.1.7-nightly.20261101.4016 release page
• The phone connected to the host's private-network address

What happened Starting the browser from the phone worked in one thread. In a new thread it stayed on "Connecting to browser…". chrome-headless-shell was running the whole time, but it belonged to the first thread's tab.

Trace comparison (server.trace.ndjson, UTC, 2026-11-01)

Diagnosis ServerBrowserStream runs attachViewer before upgrading the socket (ServerBrowserStream.ts:84, :109), and attachViewer waits on startScreencast and then the first still with no deadline (ServerBrowser.ts:2605, :2608, at tag v0.1.7-nightly.20261101.4016). A desktop-rendered tab that doesn't answer therefore leaves the phone connecting indefinitely.

Not established: why the desktop tab didn't answer, and why the first tab registered no webview. One check at 11:01, during this triage session, found the T3 window not minimized and not the foreground window.

Workaround Quit the desktop app and run the server with the matching version, so new tabs open headless:

npm dlx t3@0.1.7-nightly.20261101.4016 serve

Related #27663 look like they address the hang, and both were still open when checked. Also related: #24852, #23139.

Another trigger for this on Windows: the host session is a Remote Desktop session that gets disconnected. Nobody uses the host's physical console; the account is only reached over RDP (from the same iPad that views the preview). When the RDP client disconnects (here: iOS suspends the RDP app after switching to T3), the Windows session has no display at all, the desktop app's tabs stop producing frames, and attachViewer hangs. It finishes a few seconds after the RDP session reconnects.

Environment: Windows 11 Pro (build 26200), T3 Code (Beta) desktop app 0.1.6 hosting the server; viewer is the iPad (iOS TestFlight app) over Tailscale, not T3 Connect.

Host trace (server.trace.ndjson) next to the TerminalServices-LocalSessionManager log, UTC, 2026-11-09:

The network is not involved: the iPad reaches the host directly at 13 ms, and the proxy in front of the server logs only "Opening handshake has timed out" towards T3.

So "nobody is at the host" also includes "the host's only session is a disconnected RDP session". In that state the thread being open in the T3 window doesn't help, because nothing is drawn. On Windows there is no way to make the desktop app use headless Chrome for its tabs, so a bounded attachViewer (#27663 / #25381 / #25862) plus a headless fallback when the desktop tab produces no frame would cover it. Workaround in the meantime: run tabs on a standalone t3 serve host (headless Chrome works there).