Sign up
View stargazers13Sign up

[Bug]: SSH remote environment never connects when link RTT exceeds ~1s, eg on in-flight wifi (readiness probe deadline is 1000ms)#7733

openedAug 20, 2026byRrohitgirdhar

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

Steps to reproduce

  1. Have a working SSH remote environment
  2. Make the link slow. Eg use a genuinely high-latency network (inflight or satellite wifi)
  3. In T3 Code Desktop, open (or reconnect to) that SSH environment. It never connects

Expected behavior

The environment connects. The tunnel is up, the remote server is running and answering, so a slow link should only make connecting slower, not impossible.

Actual behavior

The banner shows "Failed to connect. Reconnecting..." and the app retries forever, never succeeding.

Impact

Blocks work completely

Version or commit

0.0.33

Environment

T3 Code (Alpha) 0.0.33 (desktop, arm64), macOS 26.6.1 (Apple Silicon); remote env = Ubuntu VM via ProxyJump, remote t3 server 0.0.33 on Node 22

Logs or stack traces

shell
1# ssh.tunnel.ready.failed — tunnel is alive and listening, server is ready
2[
3 "ssh.tunnel.ready.failed",
4 {
5 "alias": "<redacted>",
6 "hostname": "<redacted>",
7 "username": "<redacted>",
8 "port": 22,
9 "command": ["ssh","-o","BatchMode=yes","-o","ConnectTimeout=10","-p","22",
10 "-o","ExitOnForwardFailure=yes","-o","ControlMaster=no",
11 "-o","ControlPath=none","-o","ControlPersist=no",
12 "-o","ServerAliveInterval=15","-o","ServerAliveCountMax=3",
13 "-n","-N","-L","50842:127.0.0.1:34877","<redacted>"],
14 "pid": 14068,
15 "processRunning": true,
16 "localPortListening": true,
17 "remotePort": 34877,
18 "httpBaseUrl": "http://127.0.0.1:50842/",
19 "remoteLogTail": "... Listening on http://127.0.0.1:34877 ... T3 Code server is ready."
20 }
21]
22
23# the cause: every probe misses a 1000ms deadline, 67 attempts inside 20s
24[
25 "ssh.environment.tunnel.create.failed",
26 {
27 "cause": {
28 "_tag": "SshReadinessError",
29 "message": "Timed out waiting 20000ms for backend readiness at http://127.0.0.1:50842/.",
30 "cause": {
31 "attempt": 67,
32 "cause": {
33 "_tag": "SshReadinessError",
34 "message": "Backend readiness probe exceeded 1000ms at http://127.0.0.1:50842/."
35 }
36 }
37 }
38 }
39]

Screenshots, recordings, or supporting files

No response

Workaround

None within the desktop app.

Use the web UI instead, which has no readiness deadline: forward the port yourself and pair a browser.

1ssh -N -L 39901:127.0.0.1:3773 <host> &
2ssh <host> 't3 auth pairing create --base-dir ~/.t3 --ttl 12h \
3 --label laptop --base-url http://127.0.0.1:39901 --json'
4open 'http://127.0.0.1:39901/pair#token=<credential>'

That works fine over the same link, which is further evidence the constraint is only the desktop probe deadline and not the transport or the server.

#4145 addresses some similar issues (making the timeout configurable) but seems to be stalled.

Bbkntr17d ago
Synced from GitHub

Reproduced on October 6, 2026 with the Windows desktop nightly and an SSH-managed Linux server running 0.0.46-nightly.20261005.2702. The background service was uninstalled; the desktop was launching and managing the remote server.

The remote server starts successfully, but the desktop intermittently rejects the working SSH tunnel during readiness checks. A later retry succeeded, including authentication.

Evidence

At 07:15:39 UTC, the desktop trace reported:

text
1SshReadinessError: Timed out waiting 20000ms for backend readiness at http://127.0.0.1:58728/.
2Backend readiness probe exceeded 1000ms at http://127.0.0.1:58728/.

The tunnel failure diagnostic reported both processRunning: true and localPortListening: true, and the remote log showed T3 Code server is ready.

After a later tunnel succeeded, three HTTP requests through that existing desktop-owned tunnel all returned HTTP 200, with time to first byte of 1.156 s, 1.222 s, and 1.198 s. A request to the same server from the remote machine itself took 0.003718 s. These successful tunneled responses exceed the desktop's one-second per-probe deadline.

Authentication finally succeeded at 07:16:46 UTC. This makes the failure intermittent on this connection rather than a permanent inability to connect.

The one-second limit was already present in the original SSH launcher commit 3772fa127ccfe1de9326067ee6ed91e079456e97 (#2361), including v0.0.22; this reproduction does not establish a newly introduced nightly regression. It confirms that the existing limitation still affects the current nightly.

Expected: a healthy remote server should remain connectable when HTTP responses through SSH take slightly over one second. Increasing or making the per-probe timeout configurable, while retaining an overall connection deadline, would address this failure mode.

Ddezchai8d ago
Synced from GitHub

Reproduced on 0.0.46-nightly.20261014.3132 (macOS desktop → Debian 13 VPS, SSH-managed server) over in-flight satellite Wi-Fi with a steady ~920–1030 ms RTT.

The remote server launches and is healthy, and the tunnel's local port is listening, but waitForHttpReady makes ~70 attempts and every one fails with Backend readiness probe exceeded 1000ms. Then it gives up with SshReadinessError: Timed out waiting 20000ms for backend readiness. A manual curl through an equivalent ssh -L tunnel to the same server returns 200 in ~1.7–2.1 s, so the per-probe 1000 ms deadline (SSH_READY_PROBE_TIMEOUT_MS) is the only blocker. The overall 20 s budget would be plenty.

Workaround: keep a manual ssh -N -L <port>:127.0.0.1:3773 tunnel and add the environment via Remote link with http://127.0.0.1:<port> + t3 pair. #7815 would fix this.

JJulius Marminge1d ago

Existing fix: #7815, already taken over by a maintainer. Its current head 82a6cf33e7 has slow initial/reuse regression tests and a Linux HTTP runtime transcript; all 26 reported checks pass. A human change-request review remains active. Current main ed9b7ca9c5 still has the one-second probe limit. No new desktop reproduction was performed in this triage pass; no duplicate PR was opened. Leaving this issue open for the existing fix.