In the desktop app, a self-hosted GitLab repo keeps showing Source control provider gitlab failed in listChangeRequests: GitLab CLI command failed. The app also can't create merge requests. Nothing in the UI says what glab actually returned, so the user can't tell whether this is a T3 Code problem, a glab problem or a GitLab server problem.
The real cause was outside T3 Code. The company nginx reverse proxy in front of GitLab decodes %2F in API paths. So GET /api/v4/projects/<group>%2F<project> returns 404 for every project, while GET /api/v4/projects/<id> works. glab mr list in the repo fails with 404 Not Found.
T3 Code shows none of that. In packages/source-control-gitlab/src/server/GitLabCli.ts, GitLabCliCommandError.detail is a fixed string ("GitLab CLI command failed."). The VcsProcessExitError cause, which holds glab's stderr, only appears in the server trace. fromVcsError also maps failureKind: "not-found" to the same generic error. The ThreadSettlementServiceV2.sweep / ThreadPullRequestServiceV2.synchronize branch-MR lookup calls this again and again (about 4,100 failures in roughly 1.5 h in the trace), and every failure looks the same.
Suggestion: put a trimmed first line of glab's stderr into GitLabCliCommandError.detail/message, as #5620 did for git (fix(vcs): surface git's stderr on GitCommandError). For example: GitLab CLI command failed: 404 Not Found.
%2F (e.g. nginx proxy_pass http://backend/;). Any glab failure that isn't auth, rate limit or spawn works too.glab auth login to that host (glab auth status shows the host as logged in).https://<host>/<group>/<project>.git remote in the T3 Code desktop app.GitLab CLI command failed. with no detail. Run glab mr list in the repo: 404 Not Found.0.1.0 (desktop app; local server reports serverVersion 0.1.0). Also checked against main at 23b550dd: same code.
Windows 11 Pro 10.0.26200 x64, Node v26.8.2, glab 1.123.0, self-hosted GitLab behind nginx
| 1 | SourceControlProviderError: Source control provider gitlab failed in listChangeRequests: GitLab CLI command failed. |
| 2 | at findLatestPrForHeadContext ... lookupBranchPullRequest ... branchPullRequest |
| 3 | at ThreadSettlementServiceV2.pullRequestFor ... ThreadSettlementServiceV2.sweep |
| 4 | [cause]: GitLabCliCommandError: GitLab CLI failed in execute: GitLab CLI command failed. |
| 5 | [cause]: VcsProcessExitError: VCS process failed in GitLabCli.execute: glab (<repo>) exited with 1 - Merge request not found. |
| 6 | |
| 7 | $ glab mr list --source-branch main |
| 8 | ERROR 404 Not Found. |
| 9 | |
| 10 | $ glab api "projects/<group>%2F<project>" -> HTTP 404 |
| 11 | $ glab api "projects/<id>" -> 200 OK |
#15660 (closed; generic "GitLab CLI command failed" on old GitLab, where the cause was also hidden). #5620 (same fix for git). #20226 and #7849 are about building GitLab project paths. None of them asks to show glab's stderr.
None in T3 Code. The GitLab admin was asked to fix the nginx proxy_pass so %2F isn't decoded.
Claude Code (claude-opus-5-5) via t3 triage
Thanks for taking a look. On my side I'm still waiting for our GitLab admin to check the nginx configuration (whether proxy_pass is decoding %2F in the API paths). I haven't had a reply from them yet. Once it's changed, I'll retest and post the results here.
Update: our GitLab admin fixed the nginx proxy_pass, so %2F is no longer decoded. glab mr list works now and the listChangeRequests errors are gone.
The MR action button still fails with the same generic GitLab CLI command failed., but this time the cause is different. From the server trace:
| 1 | ws.rpc.pullRequests.runAction -> GitLabPullRequestCli.runMergeRequestAction |
| 2 | [cause]: VcsProcessExitError: glab (<repo>) exited with 1 - Merge request not found. |
The two glab api calls before it (getDiffRefs) succeed. The failing call is glab mr merge <N> --repo <group>/<project> ... (GitLabPullRequestCli.ts executeMr). When --repo has no host, glab doesn't use the cwd's git remote. It resolves against the configured default host (gitlab.com here):
| 1 | $ glab mr view 27 # OK |
| 2 | $ glab mr view 27 --repo <group>/<project> |
| 3 | failed to get merge request 27: GET https://gitlab.com/api/v4/projects/<group>/<project>/merge_requests/27: 404 {message: 404 Project Not Found} |
| 4 | $ glab mr view 27 --repo https://<host>/<group>/<project> # OK |
| 5 | $ GITLAB_HOST=<host> glab mr view 27 --repo <group>/<project> # OK |
So with a self-hosted instance, every glab mr <subcommand> --repo action (merge, auto-merge, ready/draft, …) goes to gitlab.com. Suggested fix: pass the host-qualified repo (https://<host>/<group>/<project>) or set GITLAB_HOST from the remote when running glab mr …. Workaround for now: glab config set host <host>.
Env for this retest: Linux, T3 Code 0.1.1, glab 1.36.0.
The original point of this issue still stands: if glab's stderr were in the UI message, this would have been obvious right away.
Another update: it turns out the Linux machine had a really old glab installed (1.36.0, no idea why). I updated it to glab 1.124.0 and also removed gitlab.com from the glab config, so my self-hosted instance is now the only configured host (and the default host). After that the remaining problems are gone: the MR action button works now.