[Bug]: Mac desktop to Windows remote browser stays on Connecting indefinitely

Before submitting

Searched existing issues. [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 reports a similar spinner from iOS to macOS, but this report concerns the initial browser connection from macOS desktop to a Windows host, without a prior working stream or refresh.
Included reproduction steps, environment and relevant diagnostics.

Area

apps/desktop; browser hosting in apps/web and streaming in apps/server.

Steps to reproduce

Run T3 Code desktop on Windows and connect to its remote environment from the T3 Code desktop app on a MacBook.
Open a thread in the Windows environment.
Click Connect to [Windows environment] browser.
The panel stays on Connecting… with a loading indicator indefinitely.
Restart both computers, reconnect and repeat: the problem persists.

Expected behavior

The remote browser connects and can display development servers running on the Windows host. Initialization failures should surface an actionable error instead of an indefinite spinner.

Actual behavior

The remote environment works for agent commands, but its browser remains on Connecting. The Mac console reports:

WebSocket is closed before the connection is established.

Impact

Major degradation: cannot use the remote host's browser to inspect development servers from the Mac desktop app.

Version and environment

Both desktop applications: 0.1.1-nightly.20261020.3411.
Client: T3 Code desktop app on MacBook (macOS version/architecture not collected).
Host: Windows 11 Business, 10.0.26200, x64.
Preview-stream requests reach the host through the T3 managed relay.
Source investigated at 67c0fc0cda.

Relevant host diagnostics

Times are UTC on October 20, 2026 (Argentina local time is UTC−03:00).

Before restarting Windows, several /api/preview-stream/ws requests lasted approximately 8–109 seconds and finished with HTTP 503/interrupted traces. The interruptions do not by themselves establish the cause.
At 18:59:51–18:59:52, ServerBrowser.findTab / ServerBrowser.attachViewer failed with ServerBrowserTabNotFoundError: The server preview tab does not exist. These are historical errors, not a confirmed explanation of the post-restart failure.
Windows restarted at 19:06:16; T3 started at approximately 19:06:59.
After restarting, ws.rpc.preview.open succeeded at 19:07:43, 19:07:59 and 19:08:07, and ServerBrowser.findTab succeeded at 19:08:08 (~99.6 ms).
Subsequent preview-list RPCs succeeded. No completed post-restart attachViewer / preview-stream request span was present in the captured log window; spans may only be written when they finish.

Source investigation

ServerBrowserStream waits for ServerBrowser.attachViewer before upgrading the WebSocket. Viewer attachment waits for screencast startup and, if no live frame has arrived, an initial still capture.

On a desktop host, HostedBrowserWebview can mark an inactive server-driven guest as suspended. resolveHostedBrowserWebviewWrapperStyle then places it at −100,000 px and hides it on Windows. That helper already documents that Electron stops compositing a guest fully outside the window, even with background throttling disabled. A stalled capture here is a plausible cause of the pending handshake.

A candidate fix keeps server-driven guest webviews paintable behind the host UI even when no local panel displays them. The Mac-to-Windows flow still needs confirmation with a build containing that fix.

Workaround

No confirmed workaround. Restarting both computers did not resolve it.

@Alannjaf

Note

🤖 Claude Opus 5.5 posting on behalf of @Alannjaf

Seeing the same thing on v0.1.1 (stable) with a Linux host (Arch/Omarchy, kernel 7.2), so it doesn't look specific to Windows hosts.

Setup: T3 Code desktop v0.1.1 runs on the Linux machine. I'm viewing from a remote client. The agent opens a preview tab (preview_open → https://example.com). The tab loads fine on the host: preview_status reports visible: true, title "Example Domain", loading: false, and preview_evaluate returns the page text. The remote preview pane stays on Connecting… the whole time.

What else fails: frame capture on the host seems stuck too. preview_snapshot (save=true) failed twice:

Preview automation client server-browser disconnected during snapshot.
After closing the tab and opening a new one: Preview automation snapshot timed out after 15000ms.

Host server traces (UTC, 2026-10-21):

07:29:24 GET /api/preview-stream/ws   92552 ms  499   (ServerBrowser.attachViewer 92542 ms)
07:30:37 GET /api/preview-stream/ws   19319 ms  499   (ServerBrowser.attachViewer 19310 ms)
07:30:38 GET /api/preview-stream/ws   18463 ms  503   (ServerBrowser.attachViewer 18453 ms)
07:28:41–07:32:13  several PreviewAutomationBroker.awaitResponse spans ending at ~15000–16000 ms (timeouts)

attachViewer stays open for the whole socket lifetime, and the socket ends with 499/503 without ever producing a frame on the client. That matches the 503/interrupted /api/preview-stream/ws requests in the original report.

As far as I can tell, the remote stream worked before I updated to v0.1.1. Of the v0.1.1 changes, #20070 (picture-in-picture stops re-encoding an unchanged page) is the only one I can see that touches frame production, so it might be worth checking. That's a guess, though.

@Alannjaf

Note

🤖 Claude Opus 5.5 posting on behalf of @Alannjaf

Follow-up to my earlier comment: opening the thread's browser pane in the desktop window on the host fixes it right away. With the pane hidden on the host, the remote viewer stays on "Connecting…". As soon as the pane is open on the host, the remote viewer gets the stream.

Same Linux host on v0.1.1. This matches the cause described in #22465 (the server-driven webview is suspended or moved off-screen when no local panel shows it, so capture never starts). It's a usable workaround until that PR lands.

Same issue here on 0.1.2-nightly.20261021.3473: Windows host, viewing from a Mac over T3 Connect. The agent's preview tab (a localhost server on the Windows host) loads and works on the host, and the agent tool reports visible: false. The Mac pane stays on "Connecting…" indefinitely.

@SagePacheco

Additional confirmed reproduction on a Windows host, T3 Code Nightly 0.1.3-nightly.20261023.3592, observed 2026-10-23.

Opening the same thread's browser pane on the host immediately restored the remote browser. No app-server restart, firewall change, or T3 restart was needed.

Before opening the host pane:

The remote browser stayed on Connecting....
The localhost application returned HTTP 200 and rendered normally in a separate Edge browser.
preview_open / preview_status reported the correct page title, loading: false, and even visible: true, but the remote stream never appeared.
Multiple preview_snapshot calls failed with Preview automation snapshot timed out after 15000ms.
preview_evaluate also failed with Preview automation evaluate timed out after 15000ms.
Host traces in userdata/logs/server.trace.ndjson showed successful PreviewAutomationBroker.connect / acquireConnection, followed by awaitResponse timeouts and disconnect/reconnect.
Closing and reopening the agent-owned preview tab did not recover it.

After opening the browser pane locally on the host, the remote viewer came up immediately. A subsequent agent preview_evaluate also succeeded, reporting document.readyState === "complete" and confirming the app DOM was present.

This makes remote browsing dependent on someone opening a pane on the host, which substantially undermines unattended remote use. Please prioritize keeping remote browser capture alive independently of local pane visibility, as proposed in #22465 or an equivalent fix. If capture cannot initialize, an actionable error would also be much better than an indefinite Connecting indicator.

We have not tested a build containing #22465, nor tested hiding the host pane again after recovery, so this confirms the workaround and current failure rather than validating the proposed patch.

Posted with Codex on behalf of @SagePacheco, at the user's request.

Additional reproduction on a Fedora Linux host with T3 Code 0.1.3-nightly.20261024.3630, observed October 24, 2026.

Environment

Host: Fedora Linux 44 Workstation, x86_64, kernel 7.2.11-200.fc44.x86_64; official T3 desktop AppImage with its desktop-managed server.
Client: macOS 26.6. Initially observed in a custom Qt WebEngine wrapper displaying T3's web client through a separate companion gateway over Tailscale HTTPS; also reproduced in a separate Chromium-based web browser.
The main T3 UI and ordinary authenticated RPCs remain usable.

Observed behavior
Opening the Browser surface leaves it on Connecting..., with the URL field and navigation controls disabled. The user reports this for both local previews and public sites, rather than one particular URL.

Targeted checks

An authenticated /ws?orchestrationProtocol=2 connection upgraded successfully. preview.open, preview.list, preview.resize, and preview.close returned successful RPC responses.
In an isolated diagnostic preview, opening https://example.com/ succeeded. T3 subsequently reported navStatus._tag: "Success", title "Example Domain", and the correct URL.
The authenticated /api/preview-stream/ws?threadId=<diagnostic-thread>&tabId=<diagnostic-tab>&maxWidth=1280&maxHeight=800 request through the companion gateway received no WebSocket upgrade response before the diagnostic client's 8-second deadline.
The same stream request also timed out before the upgrade when sent through an SSH forward directly to T3 at 127.0.0.1:3773, bypassing the companion HTTP/WebSocket proxy. That test used the same valid T3 browser-session cookie and matched the gateway's upstream header behavior. An authenticated session check through that direct connection also succeeded.
Changing only the diagnostic preview to a fixed 1280×800 viewport did not resolve the direct stream timeout. The diagnostic preview and temporary forward were closed afterwards.

The 8 seconds is the probe's deadline, not a timeout error returned by T3. These checks isolate the preview stream from successful page navigation and ordinary RPC traffic; they do not identify the exact blocked capture/attachment operation.

The SSH forward still traversed the tailnet, so this does not conclusively rule out Tailscale. However, it establishes that the custom wrapper/proxy is not required to reproduce the stalled preview. I am reporting this as further remote-preview evidence rather than claiming a Tailscale-specific defect.

The host-pane visibility workaround mentioned above, and a build containing #22465, have not been tested on this host. The user also reports intermittent inability to control a preview after it appears, which resembles #19420, but that input failure has not been independently isolated here.

Posted with Codex on behalf of the account owner, at their request. Hostnames, home paths, tokens, and private conversation data have been omitted.

This is fixed on main by fd71ddc223 (#25184), first shipped in v0.1.3-nightly.20261026.3705. The reports above all predate that build.

While a viewer's screencast or a screenshot is pending, the desktop host now keeps its hidden server-driven webview painting behind the app. Before, the guest stayed offscreen and never produced a frame, so ServerBrowser.attachViewer never returned and the remote pane sat on "Connecting…".

What I ran: a desktop host (Electron under Xvfb, fresh database) with its window left on the home screen, so no local panel showed the tab. A separate web client paired to that host opened the thread's Browser panel and loaded a localhost page served by the host. Same steps on each commit:

Host commit	Result
`53896aea76` (parent of `fd71ddc`)	Stuck on "Connecting…" for over 2 minutes. The trace shows `ws.rpc.preview.open` and `ServerBrowser.findTab` complete, with no completed `attachViewer` span (the same signature as the report).
`fd71ddc223`	Stream connects in a few seconds.
main `d145077b4f`	Stream connects; it reconnects after reloading the viewer.

Before (53896aea76) and after (main):

#24852 tracks a separate case: a headless host whose first still capture never answers, plus the request for an error state instead of an endless spinner.

Closing as fixed. If it still happens on a host running 0.1.3-nightly.20261026.3705 or later, please comment with the host's version and its server.trace.ndjson spans for /api/preview-stream/ws.

I'm still seeing the remote preview stuck on "Connecting..." on 0.1.4-nightly.20261027.3770.

The host runs Linux x86_64 with the T3 desktop app and its desktop-managed server. Electron uses --ozone-platform=wayland.

I tested capture separately on a fresh example.com tab:

Open a background tab:

preview_open({
  url: "https://example.com",
  open: false,
  reuseExistingTab: false
})

This succeeds and returns the title "Example Domain" with loading:false.

Evaluate JavaScript on the returned tab. The title is readable and document.visibilityState reports "visible", but requestAnimationFrame does not fire within a 1.5-second diagnostic deadline.

Request a snapshot:

preview_snapshot({
  tabId: "<returned tabId>",
  includeImage: false
})

It fails with:

Preview automation snapshot timed out after 15000ms.

Additional reproduction on stable 0.1.5, observed 30 October 2026, after the fix referenced in the closing comment.

Environment

Host: Ubuntu 26.04.1 LTS, x86_64, kernel 7.0.0-42-generic, T3 Code Desktop and its desktop-managed server 0.1.5. The desktop session is Wayland.
Viewer: T3 Code Desktop 0.1.5 on macOS, connected directly to the host over Tailscale. This reproduction does not use the T3 Connect relay or a separately launched CLI server.
Source checked: v0.1.5, commit 6d450a4284852af137b2f3407fddd89eb76e7644.

Observed sequence

From the Mac, create a thread and ask its agent to open Google in the host's built-in browser.
preview_open({url:"https://google.com",profileId:"default",open:true,show:true}) succeeds in about 675 ms, returning title Google, URL https://www.google.com/, and loading:false.
The Mac browser pane remains on Connecting.... Two preview_snapshot calls on that returned tab fail.
Through RDP, create a separate test thread in the Linux desktop and open Google there. Its snapshot succeeds in about 124 ms.
Open that second thread on the Mac: its stream works.
Keep RDP connected but switch Linux T3 to another thread, hiding the working Google pane. The user reports that the Mac stream continues working.

Host trace evidence, UTC

12:40:38.982  PreviewAutomationBroker.awaitResponse  Success   674 ms  [preview_open]
12:40:39.017  DesktopBrowserChannel.endpoint         Success     4 ms
12:40:42.576  PreviewAutomationBroker.awaitResponse  Failure 16001 ms  [snapshot]
12:41:03.029  PreviewAutomationBroker.awaitResponse  Failure 16001 ms  [snapshot]
Both failures: Preview automation snapshot timed out after 15000ms.

12:43:28.134  PreviewAutomationBroker.awaitResponse  Success   124 ms  [second thread's snapshot]
12:44:18.366  ServerBrowser.attachViewer             Success   220 ms

The 15,000 ms figure is the reported error; the corresponding broker spans lasted about 16 seconds. Desktop webview registration and the server's desktop-channel attachment succeeded.

Evidence boundary
This confirms a remaining remote-startup/capture symptom on 0.1.5, with a working comparison on the same host and client. The comparison used a different thread and tab: it does not prove that showing the original failed tab locally repairs it, that pane visibility is the sole cause, or that the exact fault fixed by #25184 has returned. No T3 configuration, service, database, or installed source was changed.

Once streaming worked, the user also reported that clicks and scrolling failed after Take control while address-bar navigation worked. That input symptom is being reported separately on #26796.

Navigation Menu

Repository navigation

[Bug]: Mac desktop to Windows remote browser stays on Connecting indefinitely #22461

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version and environment

Relevant host diagnostics

Source investigation

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Mac desktop to Windows remote browser stays on Connecting indefinitely #22461

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version and environment

Relevant host diagnostics

Source investigation

Workaround

Activity

Alannjaf commented on Oct 21, 2026

Alannjaf commented on Oct 21, 2026

dpearson2699 commented on Oct 21, 2026

SagePacheco commented on Oct 23, 2026

illumin3dpb-ship-it commented on Oct 24, 2026

juliusmarminge commented on Oct 27, 2026

odzangba commented on Oct 27, 2026

justinehler commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions