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

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/7733)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/7733)

---

### Before submitting

- [x] I searched existing issues and did not find a duplicate.
- [x] 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
# 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](https://github.com/pingdotgg/t3code/pull/4145) addresses some similar issues (making the timeout configurable) but seems to be stalled.