[Bug]: After a preview automation timeout, the session fails over to a client on another machine that doesn't have the thread open #13540

Activity

1. juliusmarminge commented on Sep 25, 2026

   

   juliusmarminge

   on Sep 25, 2026

   Member

   More actions

   Triage: #13540

   Verdict: Confirmed bug, still present on main. Not a duplicate. No newer commit fixes it.

   Severity: High for any environment with a second desktop connected. After one automation timeout, later preview tools run on the other machine and the shared tab is overwritten with that machine's load failure. The agent then acts on a different page from the one on screen.

   User version: Nightly 0.0.43-nightly.20260924.2223, which already includes #13064 (merged 2026-09-24). PreviewAutomationBroker.ts has not changed since that PR. Current main (d23eab13d9) has the same selection logic.

   What is wrong

   A preview-automation timeout disconnects the host and deletes that session's lease. The next call is treated as unassigned and may be given to any other client in the environment, including a desktop that does not have the thread open. That choice is then pinned for the life of the other client's connection. The original machine reconnecting, focusing, and owning the visible tab does not take the session back.

   The other client loads the tab URL on its own network. localhost, 127.0.0.1, and *.orb.local fail there. It reports that failure into the shared preview session, so the machine the user is watching covers the real page with "This site can't be reached". Reload on the watching machine fixes the shared snapshot until the next agent preview call, which is still pinned to the other machine.

   Why the code does this

   On an unanswered request, the broker disconnects that host and completes its stream so it can reconnect. Disconnect drops every lease on that connection:

         const result = yield* Deferred.await(deferred).pipe(Effect.timeoutOption(timeoutMs));
         return yield* Option.match(result, {
           onNone: () =>
             Effect.gen(function* () {
               // An unanswered request invalidates this connection. Do not replay
               // actions: the client may have applied them before becoming unreachable.
               yield* disconnect(connection.clientId, connection.queue, true);
               return yield* new PreviewAutomationTimeoutError(requestContext);
             }),

   With no live lease, the next call sorts every host in the environment. Owning the tab is only a sort key. A host with no liveTabs is still eligible, and the winner is stored as the new lease:

         // Keep one provider session on one physical desktop runtime so a
         // multi-step browser interaction cannot jump between independent
         // Electron cookie/DOM state. A live assignment that predates an
         // operation is not silently moved to a newer client: the caller gets a
         // capability failure and can deliberately start a fresh provider
         // session. A dead lease is pruned above and may fail over.
         const ownsTargetTab = (host: ClientConnection, visibleOnly = false) =>
           host.liveTabs.some(
             (tab) =>
               tab.threadId === input.scope.threadId &&
               (!visibleOnly || tab.visible === true) &&
               (input.tabId === undefined || tab.tabId === input.tabId),
           );
         const connection =
           hasLiveAssignment && supportsOperation(assignedConnection, input.operation)
             ? assignedConnection
             : hasLiveAssignment
               ? undefined
               : Array.from(current.clients.values())
                   .filter(
                     (host) =>
                       host.environmentId === input.scope.environmentId &&
                       supportsOperation(host, input.operation),
                   )
                   .sort(
                     (left, right) =>
                       Number(ownsTargetTab(right, true)) - Number(ownsTargetTab(left, true)) ||
                       Number(ownsTargetTab(right)) - Number(ownsTargetTab(left)) ||
                       Number(right.focused) - Number(left.focused) ||
                       right.focusOrder - left.focusOrder,
                   )[0];

   A client on the new-thread screen reports liveTabs: [] until it is asked to run a command. Its window still counts as focused when it is the foreground window (document.hasFocus() and visibilityState === "visible"). Two windows can both be focused, one per machine.

   That leaves two ways the idle machine wins:

   1. The next call arrives while the timed-out host is still reconnecting. The idle client is the only candidate and is pinned.
   2. The original host has reconnected but has not reported focus yet. Registration sets focused: false and liveTabs: []. If the other window is focused, it sorts first. The pin then sticks after the original host reports the visible tab.

   #13064 only changes selection when there is no live lease, and it says it does not move a session already pinned to another browser. This is that remaining case. The tests lock it in: fails over a pinned provider session only after its host disconnects and evicts an unanswered host and lets later calls use a healthy runtime both expect the next call to go to a second host that never reported the tab.

   Why the watching preview shows the error

   The idle client does not refuse a tab it has never opened. It lists the shared session, waits for a local webview, and navigates that webview (PreviewAutomationHosts.tsx, navigate around the requireReadyTab path). liveTabs only includes tabs whose desktop state has web contents, so this client does not look like an owner until after it has already been pinned and has built its own webview.

   That webview's LoadFailed status is always reported. PreviewManager.reportStatus writes it onto the shared session with no check of which client owns the visible tab. Every client applies the failed event. PreviewView then hides the real surface and shows PreviewUnreachable. Reload goes through the local webview, which can still reach the site, and reports success. The next agent command is still on the other machine, so it fails again.

   preview_evaluate returning chrome-error://chromewebdata/ with a different document creation time matches a newly created webview on the other machine, not the page already open on the first. Public URLs working is the same path: the other machine can resolve those names.

   Related issues

   Issue	Relationship
   #13051 / #13064	Fixed new-session routing to the visible tab. Explicitly does not move an existing pin. This report is that gap.
   #12319	Open. Zoomed preview_resize is a reliable way to hit the 15s broker timeout. Trigger only.
   #12273	Open. A 500ms follow-up status after other preview tools can also evict the host. Trigger only.
   #12146	Closed. Host failed to reconnect after eviction. Reconnect now works; this bug is where the session goes during that gap.
   #11167	Closed. Routing to a suspended mobile client. Different host class.

   Fixing the timeout triggers removes the usual way in. Any other unanswered preview request can still hand the session to the wrong machine.

   Fix direction

   On failover, do not select a host that does not own the thread's tab. If none does, return PreviewAutomationNoAvailableHostError and do not write a lease. The reconnecting owner can take the next call once focusHost reports liveTabs.

   Keep today's behavior for a new session that is opening the first tab: no host owns a tab yet, so the focused client should still be eligible. The dangerous case is an existing tab whose owner disappeared for the reconnect gap. input.tabId is usually set by the preview tools; a dropped lease currently forgets the last tab id, so retain it across the disconnect or treat "tab id present and nobody owns it" as no host.

   Do not move a live lease just because another client is focused. That was an intentional #13064 limit so cookies and DOM stay on one runtime. A narrow reclaim is still worth it for the already-pinned case: the pinned host does not have the tab visible, and another host does.

   Also stop applying one client's LoadFailed to the shared snapshot that every other client renders. Routing is the main fix; this is what makes the idle machine paint over the preview the user is looking at.

   Replace the two failover tests above. They currently require the bug. Add coverage for: second client connected with empty liveTabs, timeout, original host reconnects and reports the visible tab, later calls stay on the original host (or fail with no host during the gap), and the idle client never receives the command.

   Workaround

   Close the other desktop app. The lease is dropped with that connection, and the next call can select the machine that has the thread open. Quitting only the watching app does not help while the other one stays connected.

   Confidence

   High on the mechanism. It matches the reported trace shape (timeout, disconnect, reconnect about a second later, later commands absent from that machine's desktop trace until the other app exits) and the shared LoadFailed overlay. Not re-run on two desktops in this triage.
2. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   on Sep 25, 2026
3. coygeek commented on Oct 3, 2026

   

   coygeek

   on Oct 3, 2026

   More actions

   Summary

   This corroborates #13540 rather than proposing a separate issue. With two macOS desktop clients connected to one T3 Code environment, a preview timeout was followed by later tool calls running on the other machine. The calls still supplied the same explicit tabId. A loopback URL that worked on the machine running the application then failed from the newly selected host.

   Steps to reproduce

   The following describes the recorded failure sequence with a generic site and anonymized hosts. It has not been repeated in a fresh two-host test during this investigation. The smallest missing reproduction detail is the host reconnect and focus timing needed to make the second host win after the timeout.

   1. Run T3 Code and a local test site on Host A. For example, serve a static page at http://localhost:5173 on Host A only.
   2. Connect a second desktop client on Host B to the same T3 Code environment.
   3. On Host A, open the test page in the thread's preview. Retain the returned tab ID and confirm the page loads.
   4. In the same agent session, call preview_wait_for for text that never appears with timeoutMs: 10000. In the recorded session, a preview_resize timeout also preceded the host change.
   5. After the timeout, call preview_status and preview_navigate for the same explicit tab ID. Keep using http://localhost:5173 as the generic navigation target.
   6. Compare the automation host handling these requests before and after the timeout, and confirm from Host A that its HTTP server is still reachable.

   Expected behavior

   Subsequent commands for an existing tab should keep its physical browser host, or return a clear temporary host-unavailable error while that host reconnects. A condition miss must not silently make the session control an independent browser on another machine. Retaining an explicit tab ID should retain the intended browser context.

   Actual behavior

   After the timeout, the automation client changed from Host A to Host B. Later calls with the same explicit tab ID used Host B's native browser. Navigation to the loopback service failed there while the original application remained reachable on Host A.

   One returned status had a saved viewport setting of 1280 x 800 and a measured viewport of 1843 x 1152. This mismatch was another signal that the tool state and the browser being controlled no longer matched. It does not establish the cause of the timeout or host change.

   Affected area

   apps/server/src/mcp/PreviewAutomationBroker.ts, with visible effects in the desktop preview and apps/web automation host. The failure is host affinity for an existing tab after a timeout. The wait and resize timeouts are observed triggers, not separate defects in this report.

   Runtime or environment

   Two macOS desktop clients connected to one environment, using T3 Code's collaborative preview tools. The exact desktop and server builds used for the recorded failure have not been established in this investigation. The upstream source below was inspected at main commit fed41fa88bb27cb4325cb208d571393850bc63c2; that is a source inspection revision, not a claim about the original running build.

   Evidence

   The recorded browser verification notes state that an ordinary page-condition timeout disconnected the assigned automation host and a subsequent call selected the other machine's native browser. The tool observations also distinguished the automation clients before and after the timeout. Original logs and screenshots are omitted because they contain unrelated private application context. Host labels and the test URL above are anonymized examples, not literal log values.

   The public broker source still has the mechanism identified in #13540. Its timeout path disconnects an unanswered host. Connection removal deletes its assignments. Host selection treats ownership of the target tab as a sorting preference, while another capable host in the environment remains eligible. A new live assignment is then retained across later operations. This verifies the source mechanism and matches the observations, but does not prove the exact reconnect timing of the recorded incident.

   Impact

   Major degradation during local browser verification. The agent can inspect or navigate a different physical browser from the one that can reach the local application, despite continuing to target the same tab ID.

   Additional context

   #13540 is the existing report for this failure and #13772 is an open proposed fix. #12898 covers a related preview_wait_for deadline race. This report should be added as corroborating evidence on #13540, not opened as a duplicate issue.

   A reachable temporary tunnel URL allowed verification to continue across the two hosts. That avoided the loopback reachability symptom; it did not verify that host affinity was restored.

   A regression check should use two hosts and an existing tab owned by Host A. After a condition timeout or an unanswered request, commands for that tab should either stay on Host A or fail clearly until it reconnects. Host B must not receive commands for the retained tab merely because Host A is reconnecting. Once Host A reports the tab again, the same session should resume there.
4. janpilu commented on Oct 6, 2026

   

   janpilu

   on Oct 6, 2026

   More actions

   Posted by Claude (Opus 5.5, running inside T3 Code) on behalf of @janpilu, at their request. The reproduction was run by an agent on their machine.

   Still reproduces on Nightly 0.0.46-nightly.20261005.2667 (commit 37de6cbde65c), macOS 26.6.2 arm64, Electron 44.4.2. Two things this adds to the report:

   1. A trigger that needs no zoom or resize. Any request that hits the broker deadline does it. preview_evaluate with a promise that never resolves times out after 15 s every time.
   2. Recordings get split across hosts. preview_recording_stop goes to the other host, which has no recording for that tab. The recording itself is fine and is still running on the original host.

   Repro

   Two desktop clients were connected to one environment: A preview-f2725c8c… and B preview-ea4278c9…. The page was a throwaway local HTTP server on 127.0.0.1, with no auth.

   preview_open({ open: true, reuseExistingTab: false, show: false })          // -> tab_d
   preview_navigate({ tabId: "tab_d", url: "http://127.0.0.1:61606", readiness: "load" })
   // identity probe: an evaluate that throws names client A in its error
   // on A: window.t3ReproMarker = "client-A", document.cookie = "t3_repro=client-A"
   
   preview_recording_start({ tabId: "tab_d" })                                  // recording: true on A
   preview_evaluate({ tabId: "tab_d", expression: "new Promise(() => {})", awaitPromise: true })
   // -> "Preview automation evaluate timed out after 15000ms."
   preview_recording_stop({ tabId: "tab_d" })
   // -> "Preview automation recordingStop failed on client preview-ea4278c9…"   (B)

   After that, the same explicit tabId: "tab_d" reaches B:

   { "url": "chrome-error://chromewebdata/", "marker": null, "pageInstance": null }

   Server trace (server.trace.ndjson, UTC 2026-10-06)

   Time	Span	Note
   07:39:32.820	PreviewAutomationBroker.invoke	evaluate, 15 001.7 ms, PreviewAutomationTimeoutError
   07:39:47.820	PreviewAutomationBroker.disconnect	same trace as the timeout
   07:39:47.835	PreviewAutomationBroker.invoke	recordingStop sent to B 15 ms after the disconnect
   07:39:48.827	PreviewAutomationBroker.acquireConnection	A reconnects about 1 s later, too late

   B's underlying error, which the tool result reduces to "failed on client" (#15336):

   Preview automation request preview-1798 found no active recording for tab tab_d on environment <env> thread <thread>.
   

   To get the video back, I forced the same timeout on B. The next preview_recording_stop went back to A and returned the original recording: 3.26 MB, 56.5 s, 566 decoded frames. So the recording wasn't lost. The stop request just went to the wrong host.

   The lease-retention approach in #13772 looks like it covers this, because recordingStop would then only go to the host that owns tab_d. It may be worth adding a broker test for recording start → timeout → stop. We hit this in four separate verification threads on Oct 3 and Oct 5, and it's the most common reason our agents give up on the integrated browser.

   Separately, after the timeout, ordinary preview_evaluate calls on the affected host also kept timing out until a navigation cleared the stuck evaluate. That's consistent with #16264.
5. WhiteWarrior625 commented on Oct 8, 2026

   

   WhiteWarrior625

   on Oct 8, 2026

   Last edited by WhiteWarrior625

   More actions

   Additional recorded recurrence on Linux, stock nightly 0.0.46-nightly.20261005.2702, with a local desktop and a desktop on another machine connected to the same environment. This is evidence for the pre-server-browser architecture, not a reproduction against current main.

   The same logical tab existed on both automation clients. Two 30-second navigate timeouts were followed by routing to the other client. An optional post-action status lookup then reached its 500 ms deadline and changed the selected host again. The remote desktop could not load the server machine's localhost URL. Agent-side tab metadata continued to change while the user's visible panel retained an earlier connection-refused page. The owner reported two more routing recurrences on October 8.

   Installed source confirms the shared mechanism: the provider-session lease names a client connection; timeout removes that client and lease; a later call can choose another connected desktop. The optional status lookup uses the same broker timeout path. The transport had also stalled, but we have not established the cause of that stall or claimed that client selection alone fixes it.

   I checked the newer stock 0.0.46-nightly.20261008.2819 source. It includes PR15328's environment-owned preferred browser and avoids host eviction for optional status reads. The downloaded stock artifact is retained with a matching GitHub SHA256; it has not been installed or verified live here. We will use a coordinated safe update boundary, rather than interrupt session-owned work.

   The remaining visibility distinction is also tracked by #17015. A successful agent navigation, shared URL/viewport metadata or visible: true cannot by itself certify the exact panel the user is watching. We require a check of the user-facing page and viewport before claiming a live walkthrough. No local runtime fork was installed.

   Nightly check on October 8: v0.0.46-nightly.20261008.2819, commit 5e2225671f705fcd33f1ea5591b79ba612fb6974, is still the newest published Nightly. Its packaged server confirms the environment-owned preferred browser and the non-evicting optional status path. The ordinary request timeout branch still disconnects the selected connection when updateCurrentTab is not false. That source path alone does not prove the old cross-machine failure recurs with the new browser architecture, so I am keeping the partial fix separate from live acceptance.

   The server browser status derives visibility from connected streamed viewers. That cannot identify the particular physical panel the user is watching. We still need a user-facing page/viewport check for walkthrough acceptance. Packaged server SHA256: 310635e55d11b09ef92672c2ea71d44f017cab43b26a83586b16be6ab051cfa5. No upgrade or local runtime patch was applied.