### Checklist - [x] I'm using the latest version of the extension (Run `glab --version`) - Extension version: `glab 1.114.0 (4d7c6cda7)` - [x] Operating system and version: `Linux 6.18.35.2-microsoft-standard-WSL2 x86_64` (WSL2) - [x] Self-managed instance - [x] GitLab version (if self-managed): 19.2.0 (`aa5f2af0b46`), CE - [x] I have performed `glab auth status` to check for authentication issues - [x] Run the command in debug mode and attach any useful output ### Summary On a self-managed instance served from a **subdirectory** (`http://HOST:PORT/gitlab`), `glab mr create` injects the URL path prefix (`gitlab`) into the *project path* and 404s: ``` GET /gitlab/api/v4/projects/gitlab%2Fmygroup%2Fmyproject → 404 Project Not Found ^^^^^^^^^ path prefix leaked into the project path ``` Every other command I tried builds the path correctly against the very same endpoint, including `glab repo view`, which resolves the same project through the same `projects/:id` lookup: ``` GET /gitlab/api/v4/projects/mygroup%2Fmyproject → 200 OK ``` So this is not an auth or config problem — the API base URL is right, and the token works. It is specific to how `mr create` resolves the repository. **Difference from the earlier reports.** This reproduces with a *single* HTTP remote and an explicit `-R group/project`, with **no SSH remote involved at all** — so it is not the split-host situation from #8146 / #8197, and `-R` does not work around it. #7920 describes the same symptom but was closed as `backlog::to-be-closed` with `documentation` labels, so the code path appears to be unfixed rather than fixed-and-regressed. ### Steps to reproduce Minimal — a fresh empty repo with one correct remote is enough: ```bash mkdir /tmp/glabtest && cd /tmp/glabtest && git init -q . git remote add origin http://HOST:PORT/gitlab/mygroup/myproject.git glab auth login --hostname HOST:PORT \ --api-host HOST:PORT/gitlab --api-protocol http --stdin # paste token # reads work fine glab mr list -R mygroup/myproject # this 404s glab mr create -R mygroup/myproject \ --source-branch some-branch --target-branch main --title t --description d --yes ``` ### What is the current *bug* behavior? ``` Failed to create merge request. Created recovery file: .../recover/mygroup/myproject/mr.json Run the command again with the '--recover' option to retry. ERROR 1 error occurred: * gitlab/mygroup/myproject: 404 Not Found ``` Note the project identifier in the error message: `gitlab/mygroup/myproject`. ### What is the expected *correct* behavior? `mr create` should resolve the project as `mygroup/myproject` — the same way `mr list` and `repo view` already do — and create the merge request. ### Relevant logs and/or screenshots Same repo, same remote, same `-R`, same session. Only the subcommand differs: ```console $ GLAB_DEBUG_HTTP=true glab mr list -R mygroup/myproject 2>&1 | grep '^GET' GET /gitlab/api/v4/projects/mygroup%2Fmyproject/merge_requests?page=1&per_page=30&state=opened HTTP/1.1 ^^^^^^^^^^^^^^^^^^^ correct $ GLAB_DEBUG_HTTP=true glab mr create -R mygroup/myproject \ --source-branch some-branch --target-branch main --title t --description d --yes 2>&1 \ | grep -E '^GET|404' GET /gitlab/api/v4/projects/gitlab%2Fmygroup%2Fmyproject?license=true&with_custom_attributes=true HTTP/1.1 ^^^^^^^^^ path prefix wrongly prepended {"message":"404 Project Not Found"} $ GLAB_DEBUG_HTTP=true glab repo view -R mygroup/myproject 2>&1 | grep '^GET' | head -1 GET /gitlab/api/v4/projects/mygroup%2Fmyproject?license=true&with_custom_attributes=true HTTP/1.1 ^^^^^^^^^^^^^^^^^^^ correct, and this is the same projects/:id lookup ``` `glab auth status` confirms the endpoint itself is configured correctly: ```console $ glab auth status --hostname HOST:PORT ✓ Logged in to HOST:PORT as <user> ✓ API calls for HOST:PORT are made over http protocol. ✓ REST API Endpoint: http://HOST:PORT/gitlab/api/v4/ ``` Config (redacted): ```yaml hosts: HOST:PORT: token: <redacted> api_protocol: http api_host: HOST:PORT/gitlab ``` ### Possible fix #8146 pointed at `internal/glrepo/repo.go:FromURL()` stripping the subdirectory from the git URL path and silently leaving the prefix in place when the strip does not apply. The reproduction here suggests the remaining gap is in whatever repo-resolution path `mr create` uses (and which `mr list` / `repo view` do not) — it should not consult the API host's path prefix when building the project identifier, and an explicit `-R` should short-circuit that resolution entirely. ### Impact / workaround Not blocking for us — we create merge requests through the REST API instead: ```bash glab api -X POST "projects/<id>/merge_requests" \ -f source_branch=... -f target_branch=... -f title=... ``` Worth reporting because the failure mode is confusing: reads work, auth checks out, and only this one write command 404s, so the natural first guess is a permissions or token problem.