[Bug]: LAN remote environment reconnects every ~30-45s from macOS client (browser + desktop), "arch disconnected"

[putueddy]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server / remote-access

Steps to reproduce

1. On an Arch Linux host, open T3 Code desktop and enable Settings → Connections → Network access (server binds 0.0.0.0:3773).

2. From a MacBook on the same WiFi LAN, open T3 Code desktop and add a remote environment via Settings → Connections → Add environment.

3. Pair with http://192.168.18.5:3773 (LAN IP of the Arch host).

4. Connect to the saved environment named arch.

5. Also reproducible by opening http://192.168.18.5:3773 directly in Chrome on the same Mac.

6. Observe the environment banner cycling:

   arch: Failed to connect. Reconnecting... Reason: arch disconnected.

Expected behavior

A reachable LAN remote environment should stay connected while the server is up and the network path is healthy.

Actual behavior

The UI WebSocket (/ws) disconnects and auto-reconnects repeatedly. This happens with both the macOS T3 desktop app and Chrome browser.

Recent server trace samples show WebSocket session durations clustering around 16–46 seconds before SessionStore.markDisconnected fires, even though basic LAN connectivity is fine (ping ~2–5 ms, 0% packet loss).

Impact

Major degradation or frequent failure — remote sessions are hard to use due to constant reconnect churn.

Version or commit

• Server: T3 Code desktop AppImage on Arch Linux (serverExposureMode: network-accessible, port 3773)
• Client: T3Code(Nightly)/0.0.29-nightly.20260705.729 on macOS

Environment

Server (Arch Linux)

• Hostname: arch
• LAN IP: 192.168.18.5
• WiFi: Intel Wi-Fi 6 AX201 (iwlwifi)
• Network access enabled; server listening on 0.0.0.0:3773
• No Tailscale/proxy in path; plain HTTP LAN pairing

Client (macOS)

• MacBook M4 Pro
• Same WiFi subnet (192.168.18.105)
• T3 Code desktop nightly + Chrome browser both affected

Logs or stack traces

Server runtime config:

{"host":"0.0.0.0","port":3773,"serverExposureMode":"network-accessible"}

Observed client user agents hitting /ws:

• Desktop: T3Code(Nightly)/0.0.29-nightly.20260705.729 (Electron)
• Browser: Chrome/149.0.0.0 on macOS

Sample WebSocket session durations before disconnect (from ~/.t3/userdata/logs/server.trace.ndjson*):

• Desktop: 16s, 17s, 25s, 40s, 43s, 44s
• Browser: 30s, 45s, 46s, 47s, 105s

Server-side disconnect marker observed repeatedly:

• SessionStore.markDisconnected

LAN reachability during repro:

• ping 192.168.18.105: 0% packet loss, ~2–5 ms RTT

Screenshots, recordings, or supporting files

N/A — UI banner text:

arch: Failed to connect. Reconnecting... Reason: arch disconnected.
arch disconnected.

Workaround

None reliable so far. Tailscale not yet tested on this setup.

Related

This looks like the same failure class as WebSocket/health-check reconnect churn on imperfect or busy links, not orphaned server processes:

• [Bug]: UI WebSocket disconnects/reconnects continuously over mildly lossy or packet-reordering links (e.g. WireGuard), despite a healthy server #3054 — WS reconnect loop over imperfect remote links
• [Bug]: Local desktop environment enters reconnecting after foreground health check timeout #3553 — false reconnect after 15s foreground health check timeout on busy backend
• Raise RPC WebSocket ping interval to prevent reconnect loop on large workspaces #3500 — RPC WebSocket ping interval too aggressive on large/busy workspaces

Not the same as #2614 (orphaned t3 serve process leaks) — no orphaned t3 serve processes observed on the server host.

[putueddy]

Update: repro also confirmed over Tailscale, not just plain LAN WiFi.

Tailscale setup

• Server (arch): 100.81.203.53
• Client (MacBook M4 Pro, T3 desktop nightly 0.0.29-nightly.20260705.729): 100.79.73.43
• Tailscale shows direct path between nodes.

What works over Tailscale

• GET http://100.81.203.53:3773/ -> 200
• GET http://100.81.203.53:3773/.well-known/t3/environment -> returns environment metadata
• OAuth pairing + POST /api/auth/websocket-ticket succeed from macOS T3 desktop app

What still fails

• UI still shows arch: Failed to connect. / reconnect churn
• Server trace shows Tailscale /ws sessions lasting only ~38–44s before SessionStore.markDisconnected
• Example durations over 100.81.203.53:3773/ws?wsTicket=...: 39s, 44s, 38s

Additional observation

While reproducing, server had multiple simultaneous clients connected (LAN + Tailscale), with very large TCP Recv-Q backlogs on established :3773 sockets (multi‑MB). That suggests the backend may be too slow to drain WebSocket traffic while reconnect loops are happening.

Tailscale improves reachability, but does not fix this reconnect bug.