[Bug]: macOS Source Control reports installed Homebrew gh as unavailable

Before submitting

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

Area

apps/desktop

Observed sequence

1. T3 Code 0.0.33 was installed as the packaged macOS app.
2. GitHub CLI was installed and authenticated:
   • gh --version succeeded in Terminal.
   • gh auth status showed an authenticated GitHub account.
3. In Settings → Source Control, GitHub appeared as unavailable with the instruction to install gh.
4. Rescan server environment did not make GitHub available.

This is an observation from one real packaged-app session, not yet a deterministic clean-environment reproduction.

Expected behavior

Following the documented setup—installing gh, authenticating it, and rescanning the server environment—should make GitHub available in Source Control.

Actual behavior

GitHub was shown as:

Not available on this server: Install the GitHub command-line tool (gh).

T3's logs from the affected session contain:

VcsProcessSpawnError: source-control.discovery.probe: gh
PlatformError: NotFound: ChildProcess.spawn (gh --version)
Error: spawn gh ENOENT

This establishes that Source Control could not resolve the gh executable and failed before GitHub authentication was evaluated.

What has and has not been established

Established:

• The packaged app was T3 Code 0.0.33.
• gh 2.93.0 was installed and authenticated.
• A real executable was available at /Users/toviastorres/.local/bin/gh; Homebrew also exposed /opt/homebrew/bin/gh.
• The Source Control probe failed with spawn gh ENOENT.
• The documented Rescan server environment action did not recover discovery in the affected session.

Not yet established:

• The exact PATH seen by the original T3 server process was not captured directly.
• The outputs or failures of T3's login-shell and launchctl PATH probes were not captured.
• A local application modification and an application restart occurred together afterward, so the later successful discovery does not isolate whether the restart, the modification, or their combination changed the result.
• Therefore, a missing standard-directory fallback is a hypothesis, not a confirmed root cause.

Related issues

• #1787 / #1799 address Homebrew-installed provider CLIs not being detected by the packaged macOS app. This may be a regression or an uncovered path through the same environment-hydration area.
• This differs from #7581, where T3 finds gh but reports the wrong authentication state.
• This differs from #3806, which involves a gh version too old to support the authentication JSON probe.
• This differs from #2187, which involves a shell alias and 1Password-based authentication.

Impact

Major degradation or frequent failure

Version or commit

0.0.33 (3b72d17cbca691f0b64e6d4a10c9e349f42873a5)

Environment

• macOS 26.6.2
• Apple Silicon (arm64)
• Packaged T3 Code desktop app 0.0.33
• GitHub CLI 2.93.0
• GitHub authentication stored in the keyring

Suggested investigation

It may help to log, alongside the failing Source Control probe:

• the effective server PATH;
• whether the login-shell probe succeeded, timed out, or returned an unusable value;
• the value returned by launchctl getenv PATH;
• which environment source was ultimately selected.

That would distinguish a shell-probe failure, environment propagation issue, stale process state, or provider-specific discovery issue without assuming a particular fix.

Workaround status

No workaround was isolated conclusively. Restarting the app was not tested independently from the local application modification. The documented rescan action did not resolve the affected session.

Start in the apps/desktop Source Control discovery probe and the server environment hydration path. Reproduce the packaged macOS case while logging the effective PATH, login-shell result, launchctl PATH, and selected environment source. Done means the cause is isolated and GitHub becomes available after the documented install, authentication, and rescan flow.