[Bug]: T3 Code does not detect GitLab CLI installed via WinGet on Windows

[WojakGra]

Before submitting

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

Area

Not sure

Steps to reproduce

1. Install GitLab CLI on Windows using WinGet:

winget install glab.glab

2. Verify that GitLab CLI is installed:

glab --version

3. Restart T3 Code.
4. Open a project hosted on GitLab.
5. Try to use a GitLab-related feature or execute glab from the environment used by T3 Code.

Expected behavior

T3 Code should detect the installed glab executable and allow GitLab-related features to use GitLab CLI.

Actual behavior

T3 Code does not detect GitLab CLI and reports that glab is unavailable, even though it was installed using WinGet and is available from a regular Windows terminal.

Impact

Blocks work completely

Version or commit

No response

Environment

Windows 11

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Thanks for the report — this looks like a real Windows PATH / WinGet discovery gap for the GitLab hosting CLI, not a duplicate of the nearby issues.

What we think is happening

T3 does not search for glab in WinGet’s install dir. Source Control probes glab --version (then glab auth status) by spawning the bare command name against the server process PATH:

• apps/server/src/sourceControl/SourceControlProviderDiscovery.ts (probeCli)
• apps/server/src/sourceControl/GitLabSourceControlProvider.ts (executable: "glab")
• apps/server/src/sourceControl/GitLabCli.ts (always command: "glab")

Any probe failure is shown as “not found on the server PATH,” including a genuine ENOENT.

On Windows, PATH hydration (apps/server/src/os-jank.ts → resolveWindowsEnvironment, and the desktop equivalent in apps/desktop/src/shell/DesktopShellEnvironment.ts) does two things that miss a WinGet install:

1. The PowerShell probe uses [Environment]::GetEnvironmentVariable('PATH') with no User/Machine target, so it reads process env (often the stale PATH a Start Menu / shortcut launch inherited from Explorer).
2. The known-dir fallbacks include npm, nodejs, Volta, pnpm, ~\.local\bin, bun, and scoop — not %LOCALAPPDATA%\Microsoft\WinGet\Links, which is where winget install glab.glab typically shims glab.exe and which WinGet adds to User PATH.

A new terminal rebuilds Machine+User PATH and finds glab. Restarting T3 does not refresh Explorer’s process PATH, so Settings → Source Control keeps reporting GitLab unavailable.

Not the same as

• [Bug]: Windows reports every provider CLI not found even when they are on User PATH #7360 — same Windows User PATH / WinGet root cause, but for Settings → Providers (opencode, grok, etc.). Related; keeping this open because it is the source-control / glab surface.
• [Bug]: installed hosting CLI reported as missing when the PATH entry is slower than the 5s discovery probe #10728 — PATH resolution succeeds and the 5s probe times out on a slow wrapper. A WinGet glab.exe shim is unlikely to be that case.
• [Bug]: macOS Source Control reports installed Homebrew gh as unavailable #7618 — same “CLI missing” message on macOS (GUI PATH / gh ENOENT).

Open PRs #9632 and #10729 (custom hosting CLI path) would let you point at the WinGet Links executable as a workaround. They do not fix automatic detection.

Workaround today

Launch T3 from a terminal that already has User PATH, or set glab’s full path once a custom hosting-CLI setting lands. Typical location:

%LOCALAPPDATA%\Microsoft\WinGet\Links\glab.exe

Next step for us

Treat this as accepted. The durable fix is Windows PATH hydration: merge persistent User+Machine PATH and/or add WinGet Links to the known CLI dirs. That would also help #7360’s WinGet cases.

If you can add one follow-up (not required to keep this open): T3 version, desktop app vs npx t3, whether you launched from Start Menu/shortcut vs a terminal, the GitLab row in Settings → Source Control, and where.exe glab.