[Bug]: GitLab MR links include the installation subfolder in the API project path, breaking reads and monitoring

Before submitting

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

Area

apps/server; packages/contracts or packages/shared

Steps to reproduce

Use a self-managed GitLab installation served at a URL prefix, such as https://code.example.com/gitlab.
Authenticate glab and configure its documented per-host installation prefix:
```
glab config set subfolder gitlab --host code.example.com
```
Use a repository whose API path is team/subgroup/project, with an SSH remote such as git@code.example.com:team/subgroup/project.git.
Link its MR in T3 using the full browser URL: https://code.example.com/gitlab/team/subgroup/project/-/merge_requests/9.
Start watching the MR.

Expected behavior

T3 preserves the browser URL, resolves the API project identity to team/subgroup/project, and successfully reads and monitors the MR.

Actual behavior

T3 stores gitlab/team/subgroup/project as the repository and calls the API with that value as the project path. GitLab returns 404. The outer T3 error is GitLab CLI command failed.

The watcher retries every two minutes and stops after eight read failures.
Restarting it repeats the failure. Successful watch registration does not establish that T3 can read the MR.

Impact

Major degradation or frequent failure

Version or commit

Release v0.1.0 and check main@e3b35d1b2440b104f0bc2e357377c348121234dd

Environment

T3 server 0.1.0, Linux, glab 1.118.0, self-managed GitLab under a URL prefix.

Logs or stack traces

The following uses placeholder host/project names corresponding to the reproduced installation. With its existing configuration and credentials:


glab config get subfolder --host code.example.com
# gitlab

glab api --hostname code.example.com 'projects/gitlab%2Fteam%2Fsubgroup%2Fproject/merge_requests/9'
# 404 Project Not Found

glab api --hostname code.example.com 'projects/team%2Fsubgroup%2Fproject/merge_requests/9'
# succeeds

glab repo view 'https://code.example.com/gitlab/team/subgroup/project' --output json
# succeeds; path_with_namespace is team/subgroup/project,
# web_url retains /gitlab/team/subgroup/project


The final command was tested successfully against the affected installation with glab 1.118.0. It returned the numeric project ID, correct `path_with_namespace`, and original `web_url`.

Screenshots, recordings, or supporting files

No response

Workaround

Not possible

Note

Grok responding on behalf of Julius.

Confirmed on main: T3 takes everything before /-/merge_requests/<n> as the project path. parseChangeRequestUrl in packages/shared/src/changeRequestUrl.ts matches ^/(.+)/-/merge_requests/(\d+), so a GitLab installed under a prefix like /gitlab ends up with gitlab/team/subgroup/project as the repository. Nothing in the GitLab provider reads glab's subfolder setting. changeRequestUrlFor also rebuilds MR URLs as https://<host>/<repository>/-/merge_requests/<n>, so it has no place for a prefix either.

Accepting this as a bug in self-managed GitLab support. Related but separate: #7849 (full URL sent as the project path on new-project lookup) and #16463 (split SSH/API hostnames).

Possible direction: once a URL has been parsed, resolve the API project identity through glab (for example path_with_namespace from glab repo view <url> --output json, as you suggested), and keep the browser URL for links. We haven't tested this yet.

Thanks for confirming. I tested glab repo view <project-web-url> --output json on the affected installation with glab 1.118.0. It returned the correct path_with_namespace and preserved the installation prefix in web_url. That validates the CLI lookup only; I haven’t tested a T3 implementation end to end.

Two cases worth covering:

Existing linked MRs already contain the incorrect repository identity, so correcting only newly created links would leave those broken.
The installation prefix and a legitimate group can both be named gitlab, so normalization must avoid stripping twice.

Also hit on macOS (arm64), desktop app nightly 0.1.1-nightly.20261020.3386, glab 1.123.0. Here the /gitlab prefix is configured through api_host: code.example.com/gitlab rather than subfolder.

It fails the same way: projects/gitlab%2Fgroup%2Fproject/... returns 404, and projects/group%2Fproject/... succeeds. The lookup that #21576 relies on also works with this setup: glab repo view https://code.example.com/gitlab/group/project --output json returns path_with_namespace = group/project.

Triage by Claude Opus 5.5 (Claude Code) via t3 triage.

Navigation Menu

Repository navigation

[Bug]: GitLab MR links include the installation subfolder in the API project path, breaking reads and monitoring #20226

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: GitLab MR links include the installation subfolder in the API project path, breaking reads and monitoring #20226

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Activity

juliusmarminge commented on Oct 16, 2026

AxxiD commented on Oct 16, 2026

sndrnz commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions