# fix\(desktop\): decouple the tunnel probe timeout from the remote loop's deadline · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/commit/3d398dbfbaaa1d1cdd369a19d7debe0e417e4244)

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

Visibility: public

Requested revision: 3d398dbfbaaa1d1cdd369a19d7debe0e417e4244

Requested commit: 3d398dbfbaaa1d1cdd369a19d7debe0e417e4244

Commit: 3d398dbfbaaa1d1cdd369a19d7debe0e417e4244

Tree: 4b689cf032e08a7f3ba1c24ff8adbe227a386101

Author: James

Committer: James

## Message

```
fix(desktop): decouple the tunnel probe timeout from the remote loop's deadline

Macroscope caught a real regression in the first pass: raising the
shared SSH_READY_PROBE_TIMEOUT_MS to 8s also fed the remote-side
reuse/launch scripts' own loopback probe. That script's deadline loop
only checks its overall timeout *between* attempts, so one in-flight
probe bounded by 8s could blow through the reuse check's 2s budget by
several seconds — a real regression the previous version didn't
account for.

Split it: SSH_READY_PROBE_TIMEOUT_MS stays 1s for the remote script
(always loopback, no RTT to account for, and must stay under
REMOTE_REUSE_READY_TIMEOUT_MS), and a new
SSH_TUNNEL_READY_PROBE_TIMEOUT_MS (8s) applies only to the desktop-side
probe that actually crosses the SSH link at initial connect. That path
uses Effect's own timeoutOption, which genuinely interrupts an
in-flight request at its outer deadline, so it can't overshoot a short
timeoutMs elsewhere the way the remote script's loop can.

```

## Parents

- [7173345bd66301c4fbaa4fbadae2109ea1ae5a00](https://git.cafe/pingdotgg/t3code/commit/7173345bd66301c4fbaa4fbadae2109ea1ae5a00?format=markdown)

[Source at this commit](https://git.cafe/pingdotgg/t3code/tree/3d398dbfbaaa1d1cdd369a19d7debe0e417e4244?format=markdown)