Summary
Connecting the desktop app to an SSH environment takes 25–60 s on our server, while plain SSH, the shell and the T3 server itself are fast. The cost comes from starting the t3 binary: every start takes about 5.5 s of CPU, and one connect starts it many times.
Measurements (0.0.46-nightly.20261011.2967, Linux x64, 4 vCPU)
t3 --version: 5.3–6.4 s wall, about 5.1 s user. A CPU profile shows about 1.3 s compiling and about 2.9 s evaluating the server bundle's top-level code, even for --version.
- A cold connect: the launch script starts
t3 4 times, about 22–28 s before the port forward opens. That is longer than the client's 15 s per-attempt establishment timeout.
- A reconnect: the client mints a pairing token over SSH (
t3 auth pairing create, about 7 s each) on every attempt and uses only the last one. auth_pairing_links shows 9 tokens in one reconnect (13:32:05–13:33:09, about 64 s) and 4 plus 1 in another.
- Ruled out: sshd options, shell init (0.06 s on the launch path), runtime download (already installed), HTTP (5–21 ms), initial shell snapshot (about 1 s), CPU throttling.
Likely mechanism (from source at ed0f7b9, not confirmed with a desktop trace)
supervisor.ts gives each attempt 15 s and retries with backoff. SshEnvironmentManager.ensureEnvironment holds a per-target lock, and the renderer calls it through Effect.tryPromise without an abort signal. A timed-out attempt keeps its desktop-side call queued on the lock, so the next attempt waits behind it, times out too, and leaves another orphan, until the backoff lets the queue drain.
Requests
- Start
t3 once per launch on the adopt path: one helper call, or read server-runtime.json and probe the port with sh/curl.
- Coalesce concurrent
ensureEnvironment calls per target and cancel orphaned calls when an attempt times out; or reuse a valid session instead of minting a pairing token on every attempt.
- Lazy-load the server bundle so
--version, __ssh-helper and auth pairing create do not evaluate it.
Related: #11287 (reconnect loop opens many short SSH sessions), #15616 (nightly retries SSH harder), #16477 (2 s reuse probe). None of them names the per-start cost combined with per-attempt pairing.
Summary
Connecting the desktop app to an SSH environment takes 25–60 s on our server, while plain SSH, the shell and the T3 server itself are fast. The cost comes from starting the
t3binary: every start takes about 5.5 s of CPU, and one connect starts it many times.Measurements (0.0.46-nightly.20261011.2967, Linux x64, 4 vCPU)
t3 --version: 5.3–6.4 s wall, about 5.1 s user. A CPU profile shows about 1.3 s compiling and about 2.9 s evaluating the server bundle's top-level code, even for--version.t34 times, about 22–28 s before the port forward opens. That is longer than the client's 15 s per-attempt establishment timeout.t3 auth pairing create, about 7 s each) on every attempt and uses only the last one.auth_pairing_linksshows 9 tokens in one reconnect (13:32:05–13:33:09, about 64 s) and 4 plus 1 in another.Likely mechanism (from source at ed0f7b9, not confirmed with a desktop trace)
supervisor.tsgives each attempt 15 s and retries with backoff.SshEnvironmentManager.ensureEnvironmentholds a per-target lock, and the renderer calls it throughEffect.tryPromisewithout an abort signal. A timed-out attempt keeps its desktop-side call queued on the lock, so the next attempt waits behind it, times out too, and leaves another orphan, until the backoff lets the queue drain.Requests
t3once per launch on the adopt path: one helper call, or readserver-runtime.jsonand probe the port withsh/curl.ensureEnvironmentcalls per target and cancel orphaned calls when an attempt times out; or reuse a valid session instead of minting a pairing token on every attempt.--version,__ssh-helperandauth pairing createdo not evaluate it.Related: #11287 (reconnect loop opens many short SSH sessions), #15616 (nightly retries SSH harder), #16477 (2 s reuse probe). None of them names the per-start cost combined with per-attempt pairing.