GitLab CLI

Open merge requests, triage issues, watch CI/CD pipelines, cut releases - your GitLab workflow from inside the container, without switching to the browser. That’s the GitLab CLI (glab), pointed at gitlab.com or your self-managed instance, and it’s what a coding agent reaches for to open an MR the moment its work is done.

git already moves your code in and out - clone, commit, push (see Git and repositories). glab covers everything around the repo on GitLab’s side. It’s a plain command-line tool, not an AI agent, and once you authenticate it the login persists across container rebuilds.

Note

acme is just a sample workbench name - it’s whatever you passed to monoceros init. Substitute your own throughout.

Added automatically with a GitLab repo

You usually don’t add this feature by hand. Configure a GitLab repo - with monoceros init --with-repos=… or monoceros add-repo - and Monoceros adds the GitLab CLI for you, authenticated from the same token as the repo. (For a self-managed host, declare provider: gitlab on the repo and set the host option below.)

Add it explicitly only when a container has no GitLab repo but you still want glab - for instance to spin up and push a brand-new project (see Start a new project).

Add it

At init, when you create the container:

monoceros init acme --with-features=gitlab

Or later, on an existing one:

monoceros add-feature acme gitlab

Remove it

monoceros remove-feature acme gitlab

Or delete the feature’s entry from acme.yml by hand and re-run monoceros apply acme - the yml is the source of truth.

Authentication

glab signs in with the same access token as your GitLab repos, so if you’ve set that up there’s nothing more to do here. Git and repositories shows how to create the token and where to put it.

Prefer to log in by hand? Leave the token unset and run glab auth login inside the container - Monoceros relays the sign-in page to your browser and completes the OAuth flow, from both monoceros shell and monoceros run. Either way the login sticks across container rebuilds.

Options

Option	Default	Description
apiToken	(empty)	GitLab PAT - see Git and repositories for scopes. Empty for glab auth login. Exported as GITLAB_TOKEN.
host	(empty)	Self-managed host (e.g. gitlab.example.com); empty targets gitlab.com. Exported as GITLAB_HOST.
version	latest	glab release to install: latest (resolved from the GitLab release API at build) or a pinned version like 1.102.0.

acme.yml

features:
  - ref: ghcr.io/getmonoceros/monoceros-features/gitlab-cli:1
    options:
      apiToken: ${GITLAB_API_TOKEN}
      host: gitlab.example.com

Tip

For a self-managed or Dedicated instance, set host - it becomes GITLAB_HOST, so every glab command targets it and you never pass --hostname. Leave it empty for gitlab.com.

What you get

The glab command on PATH, ready in any monoceros shell or via monoceros run, authenticated in every shell once a token is set.

Because it’s just glab on PATH, the AI coding tools in the container reach for it too - ask Claude Code to open an MR or check why a pipeline failed, and it shells out to glab on your behalf.