Claude Code's GitLab Support: What Changed

What changed, and when

Claude Code shipped GitLab support in two back-to-back releases: v2.1.232 on 13 August 2026 and v2.1.233 on 14 August 2026. Between them, GitLab went from "works if you already knew the workarounds" to a first-class citizen alongside GitHub in three specific places: the --worktree flag, the claude agents view, and plugin marketplaces. None of this is a rewrite of Claude Code's GitHub integration to be GitLab-shaped; it's GitLab support added directly to the same features GitHub already had.

This article is verified against Anthropic's own changelog, the worktrees documentation, the agent view documentation, and the plugin marketplace guide.

Until this week, Claude Code's GitHub integration had a head start: worktrees already understood pull request URLs, claude agents already showed PR status inline, and GitHub token leaks were already redacted automatically. GitLab users could still use Claude Code against a GitLab-hosted repository, since none of that ever depended on the host, but the conveniences that made a GitHub workflow faster simply weren't there for GitLab specifically. These two releases close most of that gap in one go rather than piecemeal over months.

GitLab merge requests in --worktree

Before v2.1.233, --worktree accepted only a bare #<number> or a GitHub-style pull request URL, and it always fetched pull/<number>/head. As of v2.1.233, it also accepts a GitLab merge request URL, such as https://gitlab.com/group/repo/-/merge_requests/123:

claude --worktree https://gitlab.com/group/repo/-/merge_requests/123

Claude Code reads only the number out of the URL, fetches that change's head commit from your repository's origin remote, and creates the worktree at .claude/worktrees/pr-<number>, same as it does for a GitHub pull request. What differs is which git ref it fetches, and that's decided by the host origin points at:

That fallback row is what actually answers the "does this reach self-hosted GitLab" question the feature raises for anyone not on gitlab.com directly. It does, it just costs one extra failed fetch attempt the first time, since Claude Code has no way to know in advance whether an arbitrary host speaks GitHub's ref convention or GitLab's.

You can also just pass the bare number, quoted so your shell doesn't read # as a comment:

claude --worktree "#1234"

For a bare number, Claude Code still needs to know which convention to try, so the same host-based logic in the table above applies.

GitLab merge requests in agent view

The claude agents view got the matching half of the same change in v2.1.233: a session working on a GitLab merge request now shows it labelled in GitLab's own reference syntax, !1234, instead of being forced into GitHub's #1234 format or left unlabelled. The label sits at the right edge of the session's row, and it's coloured by status the same way for both hosts:

!1234   yellow  waiting on checks or review, or checks failed
!1234   green   checks passed, nothing blocking
!1234   purple  merged
!1234   grey    draft or closed

You can filter the sessions list the same way for either host: type #<number> or paste a pull or merge request URL into the filter to see only the session working on that change. Nothing about the filtering syntax itself changed for GitLab, it inherited the mechanism GitHub pull requests already used.

Secret redaction learned GitLab's token formats

v2.1.232, the day before the --worktree change, added GitLab-specific secret redaction. Claude Code already scrubbed GitHub tokens it encountered in command output or file content before they could end up in a transcript or a message to Claude; as of this release it does the same for GitLab's token families.

Full redaction applies to the two routable token prefixes, glpat- (personal access tokens) and gldt- (deploy tokens). A longer list of other prefixes gets redacted as well when Claude Code recognises them: glrt-, gloas-, glptt-, glagent-, glimt-, glsoat-, glcbt-, glft-, and glffct-. This runs automatically, there's no setting to turn it on. It matters most if you're piping glab output, .gitlab-ci.yml variables, or CI logs through a session, since those are exactly the places a token is likely to show up in plain text.

The same release also extended the sandbox and credential-path protections that already covered gh's config store to glab's, so a sandboxed Bash command can't read or tamper with your GitLab CLI credentials the way it already couldn't with GitHub's.

GitLab plugin marketplaces

Also in v2.1.232: /plugin marketplace add explicitly supports GitLab as a marketplace host, on top of the general "any git host works" support Claude Code's plugin system already had. Adding one looks the same as adding a GitHub-hosted marketplace, just with a GitLab URL:

/plugin marketplace add https://gitlab.com/company/plugins.git

For a private GitLab repository, authenticate over HTTPS with a global git URL rewrite that embeds a token, since Claude Code's background auto-update pull disables credential helpers for its own git pull and needs the token in the URL itself to authenticate:

git config --global url."https://oauth2:YOUR_TOKEN@gitlab.com/acme-corp/plugins".insteadOf "https://gitlab.com/acme-corp/plugins"

GitLab's username convention for this is oauth2, GitHub's is x-access-token, and Bitbucket's is x-token-auth, three different literal strings for the same mechanism. Scope the rewrite to your specific repository or organisation path rather than the bare host, since a host-level rewrite applies to every fetch and push to that host on the machine.

For a team running its own GitLab instance rather than gitlab.com, strictKnownMarketplaces accepts a hostPattern entry so you don't have to allow-list every repository individually:

{
  "strictKnownMarketplaces": [
    {
      "source": "hostPattern",
      "hostPattern": "^gitlab\\.internal\\.example\\.com$"
    }
  ]
}

Anthropic's documentation names this as the recommended approach for both GitHub Enterprise Server and self-hosted GitLab. One syntax detail worth knowing if you're typing a self-hosted host directly: as of v2.1.196, a host without a scheme, like gitlab.example.com/team/plugins, is rejected outright rather than misread as a GitHub path. Include https:// explicitly.

A worked example: reviewing a GitLab merge request

Putting the pieces together, reviewing a colleague's merge request without touching your own working directory looks like this:

# Branch straight from the merge request
claude --worktree https://gitlab.com/acme-corp/api/-/merge_requests/482

# Claude Code creates .claude/worktrees/pr-482, fetches the MR's head commit,
# and starts a session there. Ask it to review, or point it at CI output:
> Review this merge request for anything the pipeline wouldn't catch, then
> summarise what changed and why it looks safe or risky to merge.

Because a worktree is a fresh checkout, .env and other gitignored local files won't be there unless you've set up a .worktreeinclude file to copy them in automatically. Once you're done, git worktree remove .claude/worktrees/pr-482 cleans it up, or Claude Code does it for you on exit if the worktree has no uncommitted work.

Back in claude agents, that same session now shows up labelled !482 rather than generically, coloured by whichever of the four states above the merge request is currently in, so you can tell at a glance whether it's still waiting on CI or ready to merge without switching to GitLab's own UI.

Where GitHub still has more

GitLab caught up fast across these four features, but it hasn't reached full parity with GitHub inside Claude Code yet, and it's worth being clear about where the gap actually sits rather than assuming "GitLab support" means everything GitHub has:

That last row is the one to watch. Third parties, including a community claude-code-for-gitlab project and posts from GitLab itself on running Claude Code against GitLab pipelines, have filled some of that gap already, but as of this release it isn't something Anthropic ships and documents the way GitHub Actions integration is.

What this doesn't cover

It's worth being precise about the boundary here, since a single changelog line can read as broader than it is. This release adds GitLab support to --worktree, claude agents, secret redaction, and plugin marketplaces. It is not a GitLab CI/CD integration; there's no equivalent yet to a .gitlab-ci.yml job that runs Claude Code the way GitHub Actions workflows can, and Anthropic's changelog doesn't describe one. If your workflow depends on triggering Claude Code from a GitLab pipeline rather than from your own terminal against a GitLab-hosted repository, this release doesn't change that.

What this means if you use skills

None of this touches the SKILL.md format or how skills are discovered. A skill installed at project or personal scope behaves identically whether the repository it lives in is hosted on GitHub or GitLab. The one place the two intersect is plugin marketplaces: if your team distributes skills bundled inside a plugin, that plugin's marketplace can now live on GitLab with the same first-class support it already had on GitHub, including the private-repository authentication path above.

Troubleshooting

--worktree with a GitLab URL fails with a fetch error. Confirm your repository's origin remote actually points at the host in the URL you passed; Claude Code always fetches from origin, never from an arbitrary host named in the argument. For a self-hosted instance, remember the first attempt tries GitHub's ref convention before falling back to GitLab's, so a single failed-then-succeeded fetch in the output is expected, not a sign anything is broken.

A GitLab token still shows up in a transcript. Redaction covers the documented prefixes above. A custom or renamed token format, or one embedded in a way that doesn't match the pattern Claude Code scans for, won't be caught. Treat automatic redaction as a safety net, not a reason to paste credentials into a session deliberately.

Adding a self-hosted GitLab marketplace fails immediately. Check the URL includes an explicit https:// scheme. Since v2.1.196, a bare host like gitlab.example.com/team/plugins is rejected as an invalid shorthand rather than silently misread.

Where to go next

For the general mechanics of running parallel sessions in isolated checkouts, see Anthropic's worktrees documentation directly. For distributing your own skills as a plugin, see how to write your own agent skill. If you're new to Claude Code's other recent additions, cross-session messaging and self-hosted runners shipped in the same run of August releases this one builds on. Browse the current Claude Code catalogue at getclaudeskills.com/platforms/claude-code, or everything cataloged at getclaudeskills.com/skills.