---
title: 4.1.0 — GitLab in the PRs & Issues view
layout: default
parent: English
nav_order: 1016
description: Setup guide for MulmoTerminal 4.1.0 — put a GitLab project in prRepos and its merge requests and issues appear beside your GitHub ones, with the same one-click start.
---

# 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`:

```json
{
  "prRepos": ["acme/web", "gitlab.com/group/project"]
}
```

- **A bare `owner/repo` still means github.com** — that is why your existing entries are untouched.
- **GitLab groups nest**, so `gitlab.com/group/sub/project` works too.
- You can add it from **Settings → Pull request repos** as well; the field takes the same form.

→ [GitHub integration](github.html) 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.

```bash
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](v3.0.0.html) 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](https://github.com/receptron/mulmoterminal/blob/main/docs/ChangeLog.md).
