[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

T3 Code 0.0.33 was installed as the packaged macOS app.
GitHub CLI was installed and authenticated:
- gh --version succeeded in Terminal.
- gh auth status showed an authenticated GitHub account.
In Settings → Source Control, GitHub appeared as unavailable with the instruction to install gh.
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

[Bug]: Homebrew-distributed app fails to detect Claude Code (and Codex) provider — works fine when built from source #1787 / Improve shell PATH hydration and fallback detection #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 [Bug]: gh is authenticated but t3 says gh is NOT authenticated #7581, where T3 finds gh but reports the wrong authentication state.
This differs from GitHub source control shows "Not authenticated" when gh is outdated (missing auth status --json) #3806, which involves a gh version too old to support the authentication JSON probe.
This differs from [Bug]: Git integration treats 1Password shell-plugin gh auth as unauthenticated #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.

Reproducing this on 0.0.34-nightly, with the PATH measurements the issue lists as
not-yet-established. Short version: the server process runs with the minimal
Finder-launched .app PATH, launchctl getenv PATH is unset, and so every
bare-gh spawn fails — not just the discovery probe.

Effective PATH of the running server process

Taken from the live processes via ps eww, all five T3 processes (main, helpers,
renderer):

PATH=/usr/bin:/bin:/usr/sbin:/sbin

That is the bare Finder-launch environment. It contains neither /opt/homebrew/bin
nor ~/.local/bin.

launchctl

$ launchctl getenv PATH
(no output, exit 0)

Unset — so a launchctl-based fallback has nothing to contribute on this OS version.

Where gh actually is

$ which -a gh
/opt/homebrew/bin/gh
/usr/local/bin/gh
$ gh --version
gh version 2.98.0 (2026-08-20)

Login-shell PATH (for contrast)

Order preserved, home directory and two internal tooling entries redacted:

$HOME/.rvm/gems/ruby-3.4.4/bin
$HOME/.rvm/gems/ruby-3.4.4@global/bin
$HOME/.rvm/rubies/ruby-3.4.4/bin
$HOME/.rvm/bin
/opt/homebrew/bin          <-- gh
/opt/homebrew/sbin
/usr/local/bin             <-- gh
/System/Cryptexes/App/usr/bin
/usr/bin
/bin
/usr/sbin
/sbin
<cryptex bootstrap paths>
<redacted internal path>
$HOME/.bun/bin
$HOME/.pyenv/shims
$HOME/.local/bin
/opt/homebrew/opt/php@8.3/sbin
/opt/homebrew/opt/php@8.3/bin
/opt/homebrew/opt/libpq/bin
/opt/homebrew/share/google-cloud-sdk/bin
$HOME/.nvm/versions/node/v20.19.0/bin
<redacted internal path>

So the login-shell probe would find gh if its result reached the spawn
environment. It does not.

What fails, from the trace logs

Every bare-gh spawn across a ~14h window (2026-08-24 19:39 → 2026-08-25 09:44),
counted from ~/.t3/userdata/logs/server.trace.ndjson*:

command	failures
`gh pr list`	495
`gh pr view`	222
`gh api user`	143
`gh --version` (discovery probe)	56
`gh pr diff`	18

Successful gh spawns: 0. Total VcsProcessSpawnError: 1246.

Two things worth drawing out:

It is not only the discovery probe. The pull-request surface spawns gh
independently and fails the same way, so this reads as bare-name gh spawning
throughout the VCS layer rather than one probe with a missing fallback:

{"type":"effect-span","name":"processRunner.runProcessCore", ...
  "exit":{"_tag":"Failure","cause":"ProcessSpawnError: Failed to spawn process 'gh' in '$HOME/<repo>'

NotFound: ChildProcess.spawn (gh pr list --head <branch> --state all --limit 20
  --json number,title,url,baseRefName,headRefName,state,mergedAt,updatedAt,
  isCrossRepository,headRepository,headRepositoryOwner)
  ...
  [cause]: Error: spawn gh ENOENT

gh auth status never runs — it appears zero times in the traces. That
corroborates the original report's reading that this fails before
authentication is ever evaluated, and distinguishes it from [Bug]: gh is authenticated but t3 says gh is NOT authenticated #7581 / GitHub source control shows "Not authenticated" when gh is outdated (missing auth status --json) #3806.

Environment

macOS 26.2 (25C56), Apple Silicon (arm64)
T3 Code 0.0.34-nightly.20260825.1184 (com.t3tools.t3code), packaged app, launched from Finder
Login shell /bin/zsh
GitHub CLI 2.98.0 via Homebrew, also present at /usr/local/bin/gh

Since the original report was 0.0.33 and this is 0.0.34-nightly, the behaviour is
still present on nightly.

Navigation Menu

Repository navigation

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

Before submitting

Area

Observed sequence

Expected behavior

Actual behavior

What has and has not been established

Related issues

Impact

Version or commit

Environment

Suggested investigation

Workaround status

Effective PATH of the running server process

launchctl

Where gh actually is

Login-shell PATH (for contrast)

What fails, from the trace logs

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Before submitting

Area

Observed sequence

Expected behavior

Actual behavior

What has and has not been established

Related issues

Impact

Version or commit

Environment

Suggested investigation

Workaround status

Activity

jarrodplacide commented on Aug 25, 2026

Effective PATH of the running server process

launchctl

Where gh actually is

Login-shell PATH (for contrast)

What fails, from the trace logs

Environment

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions