Skip to content

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

Open
#7815
Open
[Bug]: SSH remote environment never connects when link RTT exceeds ~1s, eg on in-flight wifi (readiness probe deadline is 1000ms)#7733
#7815
Labels
bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

Description

@rohitgirdhar
rohitgirdhar
opened on Aug 20, 2026

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

# 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

  1. rohitgirdhar
    added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Aug 20, 2026

  2. bkntr commented on Oct 6, 2026

    @bkntr
    bkntr
    on Oct 6, 2026
    Contributor

    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:

    SshReadinessError: Timed out waiting 20000ms for backend readiness at http://127.0.0.1:58728/.
Backend 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions