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

Activity

1. WojakGra

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 9, 2026
2. juliusmarminge commented on Sep 9, 2026

   

   juliusmarminge

   on Sep 9, 2026

   Member

   More actions

   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.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   acceptedfeature request acceptedfeature request accepted

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 9, 2026
4. WojakGra commented on Sep 10, 2026

   

   WojakGra

   on Sep 10, 2026

   Author

   More actions

   • T3 version: 0.0.40
   • Desktop App
   • I always start from Start Menu
5. WojakGra commented on Sep 10, 2026

   

   WojakGra

   on Sep 10, 2026

   Author

   More actions

   After the full restart of the computer it detected the glab, but if i use "Create MR" i get a Source control provider gitlab failed in listChangeRequests: GitLab CLI command failed.
6. Koushik890

   added a commit that references this issue on Sep 10, 2026

   fix(shared): detect Windows CLIs installed after the app's PATH snapshot

   ...

   This issue will close once commit 5685ff3 is merged into the 'main' branch.

   5685ff3
7. WojakGra commented on Sep 24, 2026

   

   WojakGra

   on Sep 24, 2026

   Author

   More actions

   @juliusmarminge is there a log to check why i get a Source control provider gitlab failed in listChangeRequests: GitLab CLI command failed. error?
8. WojakGra commented on Sep 24, 2026

   

   WojakGra

   on Sep 24, 2026

   Author

   More actions

   Okay, found them:

   {
     "type": "effect-span",
     "name": "branchPullRequest",
     "traceId": "2a3a30ad9624da74c503c787ece61188",
     "spanId": "9065aac020409f6c",
     "parentSpanId": "5e83033f2597da58",
     "sampled": true,
     "kind": "internal",
     "startTimeUnixNano": "1790254208167610400",
     "endTimeUnixNano": "1790254208941995100",
     "durationMs": 774.3847,
     "attributes": {},
     "events": [],
     "links": [],
     "exit": {
       "_tag": "Failure",
       "cause": "SourceControlProviderError: Source control provider gitlab failed in listChangeRequests: GitLab CLI command failed.\n    at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:113229:82\n    at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/claudeHistoryWorker-CAn1PawV.mjs:10021:96\n    at ~effect/Utils/internal (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/claudeHistoryWorker-CAn1PawV.mjs:2558:10)\n    at findLatestPrForHeadContext (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:169493:20)\n    at findLatestPrForHeadContext (definition) (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:169760:37)\n    at branchPullRequest (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:199683:22)\n    at branchPullRequest (definition) (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:170045:28)\n    at ThreadSettlementReactor.pullRequestFor (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:199689:31)\n    at ThreadSettlementReactor.pullRequestFor (definition) (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:199651:26)\n    at ThreadSettlementReactor.sweep (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:199699:42)\n    at ThreadSettlementReactor.sweep (definition) (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:199585:16) {\n  [cause]: GitLabCliCommandError: GitLab CLI failed in execute: GitLab CLI command failed.\n      at Object.VcsProcessExitError (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:112770:26)\n      at Object.evaluate (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:37248:117)\n      at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:37278:85\n      at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:37302:18\n      at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:37235:62\n      at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/claudeHistoryWorker-CAn1PawV.mjs:214:38\n      at GitLabCliCommandError.fromVcsError (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:112753:10)\n      at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:112937:73\n      at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/claudeHistoryWorker-CAn1PawV.mjs:10021:96\n      at ~effect/Utils/internal (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/claudeHistoryWorker-CAn1PawV.mjs:2558:10) {\n    [cause]: VcsProcessExitError: VCS process failed in GitLabCli.execute: glab (C:\\PROJEKTY\\___\\___-magazyn) exited with 1 - Merge request not found.\n        at VcsProcessExitError.fromProcessExit (file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:31121:10)\n        at file:///C:/Users/XYZ/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs:92989:87\n        at next (<anonymous>)\n  }\n}"
     }
   }
   
9. juliusmarminge

   added

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   and removed

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Oct 22, 2026
10. Pjieter commented on Oct 23, 2026

    

    Pjieter

    on Oct 23, 2026

    More actions

    Same symptom on v0.1.2 (desktop app, Windows 11 26200). I traced the cause in the source.

    Cause. On Windows the desktop app builds the server's PATH with [Environment]::GetEnvironmentVariable('PATH') in apps/desktop/src/shell/DesktopShellEnvironment.ts:212. With no scope argument, that returns the PATH PowerShell inherited from Electron, which inherited it from Explorer. It never reads the User or Machine PATH from the registry. The server's fallback (resolveWindowsEnvironment in packages/shared/src/shell.ts) does the same. So any CLI added to PATH after Explorer started stays invisible to T3 Code. Restarting T3 Code doesn't help, but a reboot does, which matches the earlier report in this thread. main still has this code.

    Evidence.

    • glab 1.124.0 installed to %LOCALAPPDATA%\Programs\glab at 14:01, with that directory on the User PATH in the registry. glab --version and glab auth status both work in a new Windows Terminal tab.
    • T3 Code was relaunched from the Start menu at 15:04, and Explorer, its parent process, had been running since three days earlier. The trace still shows ProcessSpawnError: Failed to spawn process 'glab' at 15:04:56 and 15:05:01.
    • T3 Code was then launched from a Windows Terminal shell whose PATH included glab. glab checks succeeded at 15:11:06 and 15:11:09, and the GitLab switch became clickable. Launching from the Start menu again brought the problem back.
    • Explorer was then restarted (Stop-Process -Name explorer -Force, and Windows relaunched it through userinit.exe). T3 Code launched from the new Explorer at 15:12:51 found glab at 15:13:02.

    Workarounds.

    • Tested: restart Explorer with Stop-Process -Name explorer -Force. Windows restarts it with a fresh environment.
    • Tested: start T3 Code from a new Windows Terminal tab. This only lasts for that launch.
    • Untested here: sign out and back in. A reboot worked for the earlier reporter in this thread.

    Possible fix. Read [Environment]::GetEnvironmentVariable('PATH', 'Machine') and 'User', merge them ahead of the inherited PATH, and re-run discovery when Settings → Source Control is opened. The "Install glab" hint also misleads when glab is installed but outside the server's PATH.

    Triaged with Claude Code (Claude Opus 5.5) via t3 triage.
11. WojakGra commented on Oct 23, 2026

    

    WojakGra

    on Oct 23, 2026

    Author

    More actions

    Same symptom on v0.1.2 (desktop app, Windows 11 26200). I traced the cause in the source.

    Cause. On Windows the desktop app builds the server's PATH with [Environment]::GetEnvironmentVariable('PATH') in apps/desktop/src/shell/DesktopShellEnvironment.ts:212. With no scope argument, that returns the PATH PowerShell inherited from Electron, which inherited it from Explorer. It never reads the User or Machine PATH from the registry. The server's fallback (resolveWindowsEnvironment in packages/shared/src/shell.ts) does the same. So any CLI added to PATH after Explorer started stays invisible to T3 Code. Restarting T3 Code doesn't help, but a reboot does, which matches the earlier report in this thread. main still has this code.

    Evidence.

    • glab 1.124.0 installed to %LOCALAPPDATA%\Programs\glab at 14:01, with that directory on the User PATH in the registry. glab --version and glab auth status both work in a new Windows Terminal tab.
    • T3 Code was relaunched from the Start menu at 15:04, and Explorer, its parent process, had been running since three days earlier. The trace still shows ProcessSpawnError: Failed to spawn process 'glab' at 15:04:56 and 15:05:01.
    • T3 Code was then launched from a Windows Terminal shell whose PATH included glab. glab checks succeeded at 15:11:06 and 15:11:09, and the GitLab switch became clickable. Launching from the Start menu again brought the problem back.
    • Explorer was then restarted (Stop-Process -Name explorer -Force, and Windows relaunched it through userinit.exe). T3 Code launched from the new Explorer at 15:12:51 found glab at 15:13:02.

    Workarounds.

    • Tested: restart Explorer with Stop-Process -Name explorer -Force. Windows restarts it with a fresh environment.
    • Tested: start T3 Code from a new Windows Terminal tab. This only lasts for that launch.
    • Untested here: sign out and back in. A reboot worked for the earlier reporter in this thread.

    Possible fix. Read [Environment]::GetEnvironmentVariable('PATH', 'Machine') and 'User', merge them ahead of the inherited PATH, and re-run discovery when Settings → Source Control is opened. The "Install glab" hint also misleads when glab is installed but outside the server's PATH.

    Triaged with Claude Code (Claude Opus 5.5) via t3 triage.

    Did you tried to fully restart computer?
12. Pjieter commented on Oct 23, 2026

    

    Pjieter

    on Oct 23, 2026

    More actions

    Same symptom on v0.1.2 (desktop app, Windows 11 26200). I traced the cause in the source.
    Cause. On Windows the desktop app builds the server's PATH with [Environment]::GetEnvironmentVariable('PATH') in apps/desktop/src/shell/DesktopShellEnvironment.ts:212. With no scope argument, that returns the PATH PowerShell inherited from Electron, which inherited it from Explorer. It never reads the User or Machine PATH from the registry. The server's fallback (resolveWindowsEnvironment in packages/shared/src/shell.ts) does the same. So any CLI added to PATH after Explorer started stays invisible to T3 Code. Restarting T3 Code doesn't help, but a reboot does, which matches the earlier report in this thread. main still has this code.
    Evidence.

    • glab 1.124.0 installed to %LOCALAPPDATA%\Programs\glab at 14:01, with that directory on the User PATH in the registry. glab --version and glab auth status both work in a new Windows Terminal tab.
    • T3 Code was relaunched from the Start menu at 15:04, and Explorer, its parent process, had been running since three days earlier. The trace still shows ProcessSpawnError: Failed to spawn process 'glab' at 15:04:56 and 15:05:01.
    • T3 Code was then launched from a Windows Terminal shell whose PATH included glab. glab checks succeeded at 15:11:06 and 15:11:09, and the GitLab switch became clickable. Launching from the Start menu again brought the problem back.
    • Explorer was then restarted (Stop-Process -Name explorer -Force, and Windows relaunched it through userinit.exe). T3 Code launched from the new Explorer at 15:12:51 found glab at 15:13:02.

    Workarounds.

    • Tested: restart Explorer with Stop-Process -Name explorer -Force. Windows restarts it with a fresh environment.
    • Tested: start T3 Code from a new Windows Terminal tab. This only lasts for that launch.
    • Untested here: sign out and back in. A reboot worked for the earlier reporter in this thread.

    Possible fix. Read [Environment]::GetEnvironmentVariable('PATH', 'Machine') and 'User', merge them ahead of the inherited PATH, and re-run discovery when Settings → Source Control is opened. The "Install glab" hint also misleads when glab is installed but outside the server's PATH.
    Triaged with Claude Code (Claude Opus 5.5) via t3 triage.

    Did you tried to fully restart computer?

    Restarting explorer was enough for me to get it fixed. So did not need to fully restart the computer