4.1.0 — GitLab in the PRs & Issues view
A snapshot of 4.1.0 as released on 2026-08-02. It will go out of date as the app moves on; that is fine and expected. For the reference that is kept current, follow the links to the living guide in each section.
The PRs & Issues view has read github.com since it existed. In 4.1.0 it also reads gitlab.com, and a GitLab issue starts work the same way a GitHub one does.
Nothing about your existing setup changes. Every prRepos entry you already have keeps working, unchanged, and this release adds no required configuration.
Adding a GitLab project
Write the host in front of the project path, in prRepos:
{
"prRepos": ["acme/web", "gitlab.com/group/project"]
}
- A bare
owner/repostill means github.com — that is why your existing entries are untouched. - GitLab groups nest, so
gitlab.com/group/sub/projectworks too. - You can add it from Settings → Pull request repos as well; the field takes the same form.
→ GitHub integration for the rest of the view’s setup.
What you need
glab, logged in. The GitLab CLI is to GitLab what gh is to GitHub here — the app runs it and lets it hold the credentials, so MulmoTerminal never stores a token of yours.
brew install glab # or see https://gitlab.com/gitlab-org/cli
glab auth login
If glab is missing or not logged in, that repository’s row says so instead of showing an empty section.
What works, and what does not yet
| GitHub | GitLab | |
|---|---|---|
| Merge requests / pull requests in the list | yes | yes |
| Issues in the list | yes | yes |
| Start work from an issue row (▶) | yes | yes |
| CI dot on a row | yes | partial — see below |
| ⧉ Open PR from a cell | yes | not yet |
| Work comments on the issue | yes | not yet |
| PR phase pill in the cockpit roster | yes | not yet |
A row on a host that is neither now says which host is unsupported, rather than contributing an empty section with no explanation. The same is true of the ▶ button: on an unsupported host it names the host instead of claiming you have no local clone.
The CI dot on a GitLab row is usually blank
GitLab’s merge-request list does not carry pipeline status — reading it properly costs one API call per merge request, which a view spanning several repositories cannot spend. So a GitLab row shows the dim “no checks” dot even on a project that does run CI. The exception is a merge request that CI is actively blocking, which shows as running.
The honest reading is one click away on the merge request itself. This is a deliberate limit, not an oversight — widening it would change how GitHub rows render, which this release does not do.
Starting work on a GitLab issue
Exactly as on GitHub: press ▶ on the issue row. The app reads the issue with glab, cuts an issue/<number>-<slug> worktree in your clone, and opens Claude there with the issue text waiting in the input box — not submitted, so you read it and press Enter yourself.
You need a local clone of the GitLab project registered as a directory preset, the same requirement GitHub has. → 3.0.0 — start from the issue for how that flow works in full.
Also in 4.1.0
One worktree per issue. Starting work on the same issue twice used to create issue/<N>-<slug>-2 silently. Now the second attempt opens what is already there: it reuses the worktree if no session is in it, or opens the existing session if one is — and declines, saying so, if somebody else is holding it.
Header tooltips appear instantly and say more. The cell header’s chips used the browser’s own title, whose delay cannot be changed from CSS or JavaScript, and which can only hold one line of plain text. They are now the app’s own tooltip — immediate, and the work chip finally shows the PR and issue TITLES, which the server has been sending since 4.0.0 without anywhere to put them.
Two fixes worth knowing about:
- The header’s git and work chips rendered in serif (Times). Measured in a real browser: six elements were falling back to the browser default, and these two were the only ones in the header without a font declared. Fixed — no action needed.
- On Windows, the session registry read paths with POSIX rules, so a session could be recorded against the wrong directory.
Under the hood, about half of this release is the removal of 100-plus as type assertions across the codebase, replaced by real type guards. Nothing changes on screen; it means a wrong shape from a config file or an API now fails where it enters rather than several layers later.
Full detail on every change, including the ones with nothing to configure, is in the changelog.