# fix\(client-runtime\): tolerate transient foreground probe timeouts · PR \#5198 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/pull/5198)

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

Visibility: public

State: closed

Source repository: Unavailable fork

Source branch: fix-t3code-render-glitch

Target branch: main

Head commit: 3fdbd155b93f90d9b9e24ca89ed010b3ff097887

[Discussion and reviews](https://git.cafe/pingdotgg/t3code/pull/5198)

[Commits](https://git.cafe/pingdotgg/t3code/pull/5198/commits?format=markdown)

[Files changed](https://git.cafe/pingdotgg/t3code/pull/5198/diffs?format=markdown)

## Description

---

## Problem

When the host is temporarily resource constrained, a foreground health probe can time out even though the existing session is still valid. Immediately replacing that session can start a reconnect while the same host is still stalled, leaving the client unusable until it recovers.

## Fix

Keep the existing desktop/web session after the first foreground probe timeout. A successful probe resets the count, while a second consecutive timeout still triggers normal recovery. Definite probe failures and mobile resume behavior are unchanged.

## Testing

- Focused connection supervisor suite: 35 tests passed
- Client-runtime typecheck
- Targeted lint and formatting checks

Model: GPT-5; harness: Codex.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Changes live connection monitoring and reconnect timing in client-runtime; behavior is well-covered by supervisor tests but affects when sessions are replaced under load.
> 
> **Overview**
> **Foreground health probes** on `application-active` no longer tear down the session on a single **15s** timeout when the host is briefly stalled. The supervisor keeps the existing lease, logs a warning, and only triggers normal reconnect recovery after **two consecutive** timeouts (`FOREGROUND_PROBE_TIMEOUTS_BEFORE_RECONNECT`).
> 
> A successful probe resets the counter. **Definite probe failures** and **`application-active-probe`** (mobile, **3s** timeout) behavior are unchanged.
> 
> Tests cover: one timeout stays connected; two timeouts → backoff/release; success between timeouts resets the count.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3fdbd155b93f90d9b9e24ca89ed010b3ff097887. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

<!-- Macroscope's pull request summary starts here -->
<!-- Macroscope will only edit the content between these invisible markers, and the markers themselves will not be visible in the GitHub rendered markdown. -->
<!-- If you delete either of the start / end markers from your PR's description, Macroscope will append its summary at the bottom of the description. -->
> [!NOTE]
> ### Tolerate transient foreground liveness probe timeouts in `EnvironmentSupervisor`
> - During `application-active` wakeups, a single probe timeout no longer triggers a reconnect; the supervisor only reconnects after 2 consecutive timeouts (`FOREGROUND_PROBE_TIMEOUTS_BEFORE_RECONNECT = 2`).
> - A successful probe resets the timeout counter to 0, so isolated timeouts are always tolerated.
> - `application-active-probe` signals retain the existing fail-fast behavior on timeout.
> - Two new tests cover consecutive timeout reconnection and counter reset after a successful probe.
>
> <!-- Macroscope's review summary starts here -->
>
> <sup><a href="https://app.macroscope.com">Macroscope</a> summarized 3fdbd15.</sup>
> <!-- Macroscope's review summary ends here -->
>
<!-- macroscope-ui-refresh -->
<!-- Macroscope's pull request summary ends here -->