Repository navigation
[Bug]: Agent browser stalls / drops connection on Windows when its panel is off-screen (switching threads) #17483
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop (also apps/web, the preview webview host)
Steps to reproduce
- On Windows, open T3 Code desktop and have an agent open a page with the built-in browser (
preview_open/preview_navigate). - Navigate away so the browser panel is not visible: open another thread, or another project's thread.
- Wait (a few minutes makes it obvious), with no agent browser command in flight.
- Go back, or let the agent continue with
preview_evaluate/preview_clicketc.
Expected behavior
The agent browser tab keeps running in the background, the same as on macOS. Page timers, sockets and connections stay alive, and agent automation keeps working while the user is looking at another thread.
Actual behavior
The browser session stalls or drops its connection whenever its panel goes off-screen. Agent browser commands then fail or time out (Preview automation evaluate failed on client preview-…).
Impact
Major degradation or frequent failure
Version or commit
0.0.45 (t3codeCommitHash 6c8fed3)
Environment
Windows 11 Pro 10.0.26300, T3 Code (Alpha) desktop 0.0.45, Electron 44, Claude agent provider
Logs or stack traces
PreviewOperationError: Desktop preview operation failed: evaluate.Runtime.evaluate (tab [...,"tab_2"], WebContents 5)
PreviewAutomationEvaluationError: Preview JavaScript evaluation failed in tab [...,"tab_2"]Likely cause (from reading the 0.0.45 bundles)
The browser host (oY/aY in the web bundle) keeps every tab's <webview> mounted app-wide. But when a tab is not visible and has no in-flight automation activity, the hidden style differs by platform:
// web: preview viewport host
keepPaintableWhenInactive: isMacPlatform(navigator.platform),
// hidden style -> visibility: keepPaintableWhenInactive ? "visible" : "hidden" (moved to -100000px)On macOS the hidden webview stays visibility: visible, so the guest keeps rendering. On Windows/Linux it becomes visibility: hidden, so Chromium marks the guest page hidden: document.visibilityState = "hidden", rAF stops, timers are throttled (intensive throttling after ~5 min). Pages then drop websocket/SSE heartbeats, and automation that waits on rendering fails.
The preview guests also never set backgroundThrottling: false. The main window does, but the will-attach-webview handler in apps/desktop only forces sandbox, nodeIntegration* and contextIsolation.
Workaround (local patch, applied to installed 0.0.45)
Two one-line changes (same-length byte patches to app.asar / server.asar):
apps/desktopwill-attach-webview: also setwebPreferences.backgroundThrottling = falsefor preview partitions.apps/webpreview host:keepPaintableWhenInactive: trueon all platforms, not just macOS.
Both patched bundles pass node --check. Not yet confirmed in a running app; I'll update here after verifying. If there was a Windows-specific reason for the macOS-only gate (paint cost, flicker), an alternative is to keep visibility: hidden but set backgroundThrottling: false. That alone won't stop pages that pause on visibilitychange, though.
Possibly related
#16921 (Windows snapshot/evaluate timeouts evicting the shared host) and #17009 ("No desktop browser is connected").
Activity
synteria commentedon Oct 15, 2026
Adding a clean repro of the input side of this on Windows (0.0.46-nightly.20261015.3145).
A desktop agent tab opened with
preview_open({ open: false })silently drops pointer input:preview_open({ url: "https://www.linkedin.com/in/<profile>/", open: false, reuseExistingTab: false }). The user agent confirms the desktop runtime (Electron/44.4.5).preview_evaluateinstalls capture-phase listeners ondocumentforpointerdown,mousedown,pointerupandclick, and reads the profile's More button center (333, 503).document.elementFromPoint(333, 503)returns the button's span.preview_click({ x: 333, y: 503 })returns success. Zero events reach the page, andaria-expandedstaysfalse.preview_click({ locator: 'main >> role=button[name="More"]', timeoutMs: 8000 })times out.preview_open({ tabId, open: true }), then the identical coordinate click delivers all four trusted events (isTrusted: true,pointerType: "mouse"), and the menu opens.The silent success in step 3 is the worst part for agents: they can't tell the click went nowhere. Our daily LinkedIn automation hit this on four consecutive days (Oct 12 to 15) before we traced it. Our workaround is opening any tab we interact with using
open: true.Expected: input reaches hidden tabs, or
preview_clickreturns an error when it can't deliver it. #17478 (preview_typesucceeding without the text arriving) looks like the same family.Related: #19925 (agent tabs moving to the server browser mid-session).
phillip-hirsch commentedon Oct 22, 2026
Note
Opus 5.5 posting on behalf of Phillip.
Still reproduces on 0.1.2-nightly.20261022.3541, Windows 11 Pro 10.0.26300. The desktop app runs with its local server on this PC, which is also a T3 Connect host driven from a Mac. The agent was Claude Code.
We ran a controlled toggle on one desktop-backed tab (incognito profile, a local dev page, first opened with
open: false). A second agent (gpt-6-astra, Windows computer use) changed the T3 window between calls, and the Claude agent made each call. Server span durations, 2026-10-22 UTC:preview_snapshotpreview_snapshotpreview_click,preview_type,preview_clickpreview_snapshotpreview_evaluateracingrequestAnimationFrameagainst a 1 s timervisibilityState: "visible", 390x844preview_snapshotpreview_snapshotpreview_snapshotBefore the tab was ever shown,
preview_clickfailed withlocator.scrollIntoViewIfNeeded: Timeout 14912ms exceeded. Apreview_typefailure right after it was only a side effect: it targeted a textarea that the stuck click would have opened.What this adds to the report above:
preview_evaluatekeeps working while hidden. One probe, 30 s after a failed snapshot with another thread selected, sawvisibilityState: "visible"and arequestAnimationFramecallback within 1 s. The failed snapshot's abandoned capture may still have been forcing frames, so this doesn't show whether the guest stops rendering or only capture stalls.Two smaller things seen along the way:
SNAPSHOT_TIMEOUT_MS), but the error readsPreview automation snapshot timed out after 15000ms., becauseclassifyResponseErrorrebuilds the host'sPreviewAutomationTimeoutErrorwith the broker request'stimeoutMs(default 15 s). That sent us looking for a 15 s timer.preview_resizeon a desktop-backed tab reports the wrong size. The server skips it (applySettingreturns early whentab.desktopis set) and replied 1280x800 for a 390x844 preset. The Windows client sizes the webview from the preset itself, and the page later measured 390x844.Separately, with
open: truethe Mac client attached a stream viewer to a tab that wasn't drawing on Windows. After that, evenpreview_evaluategot no reply for 16 s untilt3_preview_close. That matches #23022.