Sign up
View stargazersSign up

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

openedSep 8, 2026byVvitorpacheco

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:

    bash
    1# ~/.local/bin/gh, earlier on PATH than the real binary
    2#!/bin/bash
    3sleep 10
    4exec /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:

ts
1auth: 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

shell
1# The real binary is fine:
2$ /home/user/.local/share/mise/installs/gh/latest/.../bin/gh --version
3gh version 2.100.0 (2026-09-03) # 180ms
4
5# The name on PATH is not. Five consecutive runs, 30s timeout each:
6$ for i in 1 2 3 4 5; do timeout 30 gh --version; echo "rc=$?"; done
7rc=124
8rc=124
9rc=124
10rc=124
11rc=124
12
13# Left to run to completion, it never returns and burns CPU:
14$ time gh --version
15real 7m3.987s
16user 3m44.518s
17sys 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.

DDoresainSep 8, 2026
Synced from GitHub

This is a problem for AI providers like claude and codex too, FWIW. The hardcoded timeout causes the healthcheck to fail on a slow wrapper.