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.