Connect a GitLab project so the AI can reference your code and its structure — and so Delivery can open merge requests against it.
The GitLab Connection gives Hamster two things at once:
GitLab connects with an OAuth grant, not an app install, so one Connection covers whatever the authorizing GitLab user can see. You add another GitLab Connection only if you need to bring in a second GitLab account.
gitlab.com only. Self-managed GitLab instances are not supported.
Each project tracks one branch, which you choose when you connect it.
api. The read-only scopes would cover indexing on their own, but registering the project webhook that keeps your index fresh needs api.If you cancel on GitLab's consent screen, nothing is connected and Hamster reports "Couldn't connect to GitLab. Please try again." Closing the popup window instead leaves the connect flow waiting, and after about two minutes it times out with the same message. Either way you can start again from the same tile.
The picker is the same one GitHub uses. For each project you select, Hamster reads the branch list and lets you pick the branch to track — by default the project's own default branch. Hamster indexes code from that branch.
Confirming the selection records each project and queues its first index. Projects you clear from the selection stop syncing and their indexed content is removed, without affecting the Connection itself.
A brand-new project with no commits yet is selectable and connects normally. The first sync finds nothing to index and succeeds anyway, and the first push you make to the project is picked up and indexed like any other change.
Hamster registers a push webhook on each connected project, so a push re-indexes the project instead of waiting for a scheduled pass.
Registering the hook needs Maintainer on the project. Without it, GitLab refuses the registration; Hamster records that and leaves the project to the 15-minute reconciliation sweep, which re-checks every connected repository. The sweep is a scheduled retry, not a guarantee — it keeps a project current where it still has access, it affects only that project, and it picks changes up less promptly than the hook would.
The connected GitLab card shows how many repositories are connected and a rollup of indexing state across them: Indexing, Embedding, Indexed, Index stale, or Sync failed. A failed sync surfaces the reason so you can act on it.
If the OAuth grant expires or you revoke Hamster's access in GitLab, the card reads "Reconnect to continue syncing." Re-authorize from the connect tile and the new grant replaces the old one in place — your project selections are preserved.
Click the connected GitLab card to reopen the repository picker. Unlike GitHub, there is no installation to configure on GitLab's side and no Manage on GitLab link — an OAuth grant reaches whatever the authorizing user can see, so the project selection is the thing you manage from Hamster.
To stop indexing a project, clear it from the selection. To change which branch a project tracks, reopen the picker and choose a different one.
Delivering a Brief against a connected GitLab project pushes the delivery branch and opens a draft merge request. It stays a draft when the run finishes — mark it ready yourself when you want reviewers on it. If a merge request is already open for that branch, Hamster reuses it instead of opening a second one.
Delivery pushes with the OAuth grant that connected GitLab, so the merge request is opened by the GitLab account that authorized the Connection. Commits are authored as Hamster Agent.
The merge request is linked back to the Brief that produced it. On the Brief, the delivery control reads Open Merge Request before one exists, then becomes a state pill — Draft, Open, Merged, or Closed — linking out to the merge request on GitLab.
Review reads a delivered GitLab merge request the same way it reads a GitHub pull request: the file diffs, the discussion threads, the pipeline results, and the approve / request-changes controls all work against GitLab. Sign in with GitLab from Review so your comments and approvals post as you instead of sitting in Hamster. Three differences come from GitLab's own model, not from Hamster:
Import skills from repo reads SKILL.md files out of a connected repository and adds them to your Skills library. It works with any connected code provider, so a GitLab project can be the source.
main or develop, not a feature branch.