[Bug]: installed hosting CLI reported as missing when the PATH entry is slower than the 5s discovery probe

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Make the name gh resolve on the server's PATH to a wrapper script that is slower than 5s, rather than to the real binary. Version managers do this routinely. A minimal stand-in:

   # ~/.local/bin/gh, earlier on PATH than the real binary
   #!/bin/bash
   sleep 10
   exec /path/to/real/gh "$@"
   

2. Confirm the CLI itself is healthy and authenticated by calling the real binary directly.

3. Open Settings → Source Control and choose Rescan server environment.

Expected behavior

Either GitHub is reported as available, or the row explains that the probe timed out — something that points at the real problem.

Actual behavior

GitHub is reported as:

Not available on this server: Install the GitHub command-line tool (gh) via https://cli.github.com/ or your package manager.

The CLI is installed, on PATH, and authenticated. The message is actively misleading: it tells the user to install software they already have, and it names PATH as the cause when PATH resolution succeeded.

The mechanism is in SourceControlProviderDiscovery.ts. probeCli runs <executable> --version with DEFAULT_PROBE_TIMEOUT_MS = 5_000 and maps any failure to status: "missing". probeSourceControlProvider then discards the captured cause and substitutes a fixed string:

auth: unknownAuth("Hosting integration command was not found on the server PATH.")

So a timeout, a non-zero exit, and a genuine ENOENT are all reported to the user as "not found on PATH". The same 5s budget applies to glab and az; az already carries probeTimeoutMs: 20_000 with a comment noting that "gh and glab answer in ~0.3s" — an assumption that holds for the real binaries but not for wrappers in front of them.

Impact

Major degradation or frequent failure

Version or commit

main @ 349ce301

Environment

• Arch Linux (kernel 7.1.9), x86_64
• T3 Code dev server from main
• GitHub CLI 2.100.0, installed and authenticated
• Node 26.8.1

Logs or stack traces

# The real binary is fine:
$ /home/user/.local/share/mise/installs/gh/latest/.../bin/gh --version
gh version 2.100.0 (2026-09-03)     # 180ms

# The name on PATH is not. Five consecutive runs, 30s timeout each:
$ for i in 1 2 3 4 5; do timeout 30 gh --version; echo "rc=$?"; done
rc=124
rc=124
rc=124
rc=124
rc=124

# Left to run to completion, it never returns and burns CPU:
$ time gh --version
real  7m3.987s
user  3m44.518s
sys   4m16.829s

Related issues

• #7618 reports the same user-visible symptom on macOS, but through a different root cause: there the server's PATH genuinely lacks the CLI's directory (spawn gh ENOENT, Finder-launched .app with PATH=/usr/bin:/bin:/usr/sbin:/sbin). This report is the opposite case — PATH resolution succeeds and the probe times out on what it found. Both surface as the same "install gh" message, which is part of why the message is a problem.

Workaround

Ensure the name on PATH resolves to the real binary, by removing the wrapper or reordering PATH. There is currently no way to tell T3 Code which executable to use, so the only fix available to the user is to change their system.

Start in SourceControlProviderDiscovery.ts by reading probeCli, DEFAULT_PROBE_TIMEOUT_MS, and probeSourceControlProvider, then reproduce the issue with the documented slow PATH wrapper and Rescan server environment. Done means timeouts and other probe failures are no longer reported as a missing CLI, while a genuine missing executable still receives the appropriate unavailable status and message.