Repository navigation
[Bug]: SSH remote environment never connects when link RTT exceeds ~1s, eg on in-flight wifi (readiness probe deadline is 1000ms) #7733
Description
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
- Have a working SSH remote environment
- Make the link slow. Eg use a genuinely high-latency network (inflight or satellite wifi)
- 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
# ssh.tunnel.ready.failed — tunnel is alive and listening, server is ready
[
"ssh.tunnel.ready.failed",
{
"alias": "<redacted>",
"hostname": "<redacted>",
"username": "<redacted>",
"port": 22,
"command": ["ssh","-o","BatchMode=yes","-o","ConnectTimeout=10","-p","22",
"-o","ExitOnForwardFailure=yes","-o","ControlMaster=no",
"-o","ControlPath=none","-o","ControlPersist=no",
"-o","ServerAliveInterval=15","-o","ServerAliveCountMax=3",
"-n","-N","-L","50842:127.0.0.1:34877","<redacted>"],
"pid": 14068,
"processRunning": true,
"localPortListening": true,
"remotePort": 34877,
"httpBaseUrl": "http://127.0.0.1:50842/",
"remoteLogTail": "... Listening on http://127.0.0.1:34877 ... T3 Code server is ready."
}
]
# the cause: every probe misses a 1000ms deadline, 67 attempts inside 20s
[
"ssh.environment.tunnel.create.failed",
{
"cause": {
"_tag": "SshReadinessError",
"message": "Timed out waiting 20000ms for backend readiness at http://127.0.0.1:50842/.",
"cause": {
"attempt": 67,
"cause": {
"_tag": "SshReadinessError",
"message": "Backend readiness probe exceeded 1000ms at http://127.0.0.1:50842/."
}
}
}
}
]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.
ssh -N -L 39901:127.0.0.1:3773 <host> &
ssh <host> 't3 auth pairing create --base-dir ~/.t3 --ttl 12h \
--label laptop --base-url http://127.0.0.1:39901 --json'
open '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.
Activity
bkntr commentedon Oct 6, 2026
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:
The tunnel failure diagnostic reported both
processRunning: trueandlocalPortListening: true, and the remote log showedT3 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.
dezchai commentedon Oct 15, 2026
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
waitForHttpReadymakes ~70 attempts and every one fails withBackend readiness probe exceeded 1000ms. Then it gives up withSshReadinessError: Timed out waiting 20000ms for backend readiness. A manualcurlthrough an equivalentssh -Ltunnel 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:3773tunnel and add the environment via Remote link withhttp://127.0.0.1:<port>+t3 pair. #7815 would fix this.