[Bug]: Agent preview tools time out and the tab never reaches the viewer when a server's thread is followed from another Mac's desktop app (0.1.5) #27783

Before submitting

• I searched existing issues and did not find a duplicate. Related: [Bug]: preview_snapshot always times out for tabs in delegated child threads and for open:false tabs (macOS 0.1.1) #23936 (snapshots time out for tabs that are not on screen, macOS), [Bug]: Windows preview snapshots and remote viewing stall while T3 is completely covered #23139 (Windows, snapshots and remote viewing stall while T3 is covered), [Bug]: Clicks and keystrokes from a T3 Connect client never reach a server preview tab after Take control #26796 (input from a remote client never reaches a server preview tab), [Bug]: Preview tabs can't be seen from mobile and all automation times out (Windows desktop unattended) #23015 (tabs not visible from mobile, all automation times out).
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (preview automation broker), apps/desktop (preview host), apps/web (preview panel on a remote desktop client)

Steps to reproduce

1. Mac A ("studio") runs T3 Code (Beta) 0.1.5 and hosts the environment. A Claude Code thread runs there. The T3 window on Mac A is open and awake, but it is not showing this thread.
2. Mac B ("m1") runs T3 Code (Beta) 0.1.5 and is paired with Mac A using a fresh pairing link with the Standard permissions, including "Control previews". The user follows the thread from Mac B.
3. The agent calls preview_open with https://github.com/nios-earth and reuseExistingTab: false.
4. The agent calls preview_snapshot, then preview_evaluate with a one-line expression, then preview_resize to 1280×800.

Expected behavior

• The tab shows up in the Browser panel on Mac B, so the user can watch it and take over for sign-ins.
• Agent automation on the tab returns results, as it does when the user is working on Mac A itself.

Actual behavior

• preview_open succeeds: runtime: "server", owner: "agent", the page loads and the title is reported.
• preview_snapshot, preview_evaluate and preview_resize each fail with Preview automation <op> timed out after 15000ms.
• After each timeout the server log shows PreviewAutomationBroker.disconnect, then connect, acquireConnection and focusHost about one second later. The next call times out the same way.
• The tab never appeared in the Browser panel on Mac B, even though the Browser panel itself now opens there.
• On a first attempt a few minutes earlier, the server tab disappeared about 15 seconds after the first snapshot timeout. t3_preview_list then showed only a new tab without runtime: "server" (navStatus: Idle, viewport 1512×982), and preview_status reported available: false.
• Earlier the same day, the same thread on the same machine ran every preview tool without problems while the user worked on Mac A directly.

Version or commit

T3 Code (Beta) 0.1.5 (t3codeCommitHash 6d450a4) on both Macs.

Environment

• Host: Mac Studio, macOS 27.0 (Darwin 27.0.0), Apple silicon, default browser profile.
• Viewer: MacBook Pro M1, macOS, T3 Code desktop app paired directly with the host.
• Agent: Claude Code harness, thread hosted on Mac A.

Logs or stack traces

From Mac A's desktop.trace.ndjson (UTC). In the second attempt the host created the webview, initialized the control session and started frame capture, yet every automation call timed out:

18:46:24 PreviewManager.createTab                  Success
18:46:24 PreviewManager.initializeControlSession   Success
18:46:24 PreviewManager.updateServerTabCapturing   Success
(18:46:25 to 18:47:30: snapshot, evaluate and resize each time out after 15 s on the server)

In the first attempt, the control session broke three seconds after the tab was created:

18:44:57 PreviewManager.createTab                  Success
18:45:00 PreviewManager.updateServerTabCapturing   Success
18:45:00 PreviewManager.initializeControlSession   Failure
PreviewOperationError: Desktop preview operation failed: initializeDebugger.defaultBackground (WebContents 9)
    at PreviewManager.initializeControlSession
    at PreviewManager.createControlSession
    at PreviewManager.ensureControlSession
    at PreviewManager.restoreControlSession
    at PreviewManager.recoverDetachedControlSession
  [cause]: Error: target closed while handling command

Mac A's server.trace.ndjson shows the broker side for each call: PreviewAutomationBroker.awaitResponse fails after 16 s with PreviewAutomationTimeoutError, followed by disconnect, then connect and focusHost about one second later. The spans have no attributes, so I can't tell which client connection the broker sent each request to.

Notes

• The broker sorts candidate hosts by focus (preferred, focused, focusOrder) and then keeps the agent session's assignment. With the user on Mac B, the focused client is Mac B's desktop app, while Mac A's desktop app renders the tab in the background. If requests are routed to Mac B, nothing there can answer for a tab that Mac A renders. If they're routed to Mac A, this looks like the background-tab stall in [Bug]: preview_snapshot always times out for tabs in delegated child threads and for open:false tabs (macOS 0.1.1) #23936. Logging clientId or connectionId on the broker spans would settle which case it is.
• serverBrowser is described as hosting headless Chromium tabs "for clients without a local runtime". A desktop viewer has a local runtime, so it seems a remote desktop client can never display a tab that another machine's server hosts. If that's intended, the Browser panel on the remote client should say so instead of opening an empty local tab.

Workaround

Do anything that needs the agent's browser, such as sign-ins and screenshots, from the T3 app on the host Mac with the thread on screen.