Repository navigation
[Bug]: Preview tabs can't be seen from mobile and all automation times out (Windows desktop unattended) #23015
Description
Before submitting
- I searched existing issues and did not find a duplicate. Possibly related: [Bug]: Windows snapshot/evaluate timeouts evict the shared server-browser host and abort another open #16921 (Windows snapshot/evaluate timeouts) and [Bug]: iOS remote preview — "You have control" but taps never reach the tab; streams stuck on "Connecting to browser…" after refresh / for other tabs #19420 (remote preview stuck on "Connecting to browser…").
- I included enough detail to reproduce or investigate the problem.
Area
apps/server (preview automation / server browser), seen while the user was on the mobile client.
Steps to reproduce
- On Windows 11 desktop (T3 Code Beta 0.1.1), run a Claude Code thread. The user is away from the desktop and follows the thread from the mobile client.
- The agent calls
preview_openwithopen: trueand an external URL that redirects to a Microsoft Entra sign-in page (corporate SSO), so the user can sign in. - The agent then calls
preview_snapshot(with and withoutincludeImage),preview_evaluate(document.body.innerText),preview_navigateandpreview_wait_for. - The user tries to view the tab from the mobile client to type the credentials.
Expected behavior
- The tab opened with
open: trueis viewable and controllable from the mobile client, so the user can complete the sign-in. - Automation calls on the tab return a result, or a clear error explaining why the tab cannot be automated (e.g. no visible renderer).
Actual behavior
preview_openresponses report"visible": falseeven withopen: true; a laterpreview_statusreported"visible": true, but the user still could not see the tab on mobile ("no lo puedo ver").- Every
preview_snapshot,preview_evaluateandpreview_navigatecall timed out after 15000 ms (Preview automation snapshot timed out after 15000ms.,Preview automation evaluate timed out after 15000ms.,Preview automation navigate timed out after 15000ms.), across two different tabs. preview_wait_forwith a trivial text condition did return, reporting the page URL, so the page itself was loading.- While the agent owned the tabs, the user reported they could not sign in; closing the tabs with
t3_preview_closereleased them. Reopening a new tab gave the same result. - Workaround for AWS SSO was a device-code flow approved on the phone; for apps that only support the web redirect flow there is no way to sign in until the user is back at the desktop.
Impact
Major degradation or frequent failure (blocks any login-gated browser work while the user is on mobile).
Version or commit
T3 Code (Beta) 0.1.1.0, Windows desktop; provider Claude (Agent SDK).
Environment
Windows 11 Pro 10.0.26300, desktop app running unattended; user connected from the mobile client. Default browser profile.
Logs or stack traces
preview_open -> {"available":true,"visible":false,"url":"https://login.microsoftonline.com/<tenant>/saml2","title":"Sign in to your account","loading":false,"control":{"owner":"agent","ownedByCaller":true}}
preview_snapshot -> Preview snapshot failed: Preview automation snapshot timed out after 15000ms.
preview_evaluate -> Preview automation evaluate timed out after 15000ms.
preview_navigate -> Preview automation navigate timed out after 15000ms.
preview_status -> {"available":true,"visible":true,...,"control":{"owner":"agent","ownedByCaller":true}}
Activity
artjom-mashanin commentedon Oct 23, 2026
Note
Posted by Claude Code (Opus 5.5) on behalf of the account owner.
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:
preview_snapshottimes out, whilepreview_evaluateworks.Why, from the source (commit
5bb54a0f):(-100000, -100000). Electron doesn't composite it (apps/web/src/browser/hostedBrowserWebviewStyle.ts:51-74), soPage.captureScreenshotandPage.startScreencastnever produce a frame. JS keeps running;requestAnimationFramestill ticks.attachViewerwaits forstartScreencast(1), then forpushStill(apps/server/src/preview/ServerBrowser.ts:2408-2410), before it returns the viewer's stream.pushStill→captureViewporthas no timeout (:2346-2355). The viewer is therefore never wired up, and the client shows "Connecting…".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.It isn't the network or T3 Connect: the remote client reaches the server fine (navigation, reload and
preview_evaluatework). 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.achose369 commentedon Oct 27, 2026
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:
Connecting..., including after a fresh tab was opened.preview_open/preview_navigatereported the local Node.js application's title andloading: false; a later status reported the tab visible. That metadata did not mean the owner could see it.preview_snapshotreturnedPreview automation snapshot timed out after 15000ms.andpreview_evaluatereturnedPreview automation evaluate timed out after 15000ms.The snapshot error recurred in a later check.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.
yossi86-del commentedon Oct 29, 2026
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.