GitLab 19.3 (not yet released)

GitLab Duo CLI now supports plugins and plugin marketplaces as an experiment, introduced in GitLab Duo CLI 9.10.0. A plugin bundles Agent Skills, custom slash commands, and Model Context Protocol (MCP) servers into a single directory. A marketplace is a catalog of available plugins, hosted in a Git repository or a local directory.

GitLab Duo CLI automatically registers the official gitlab-duo-plugins marketplace the first time you use plugins.

The marketplace includes three skills for common GitLab workflows:

• mr-review: Reviews a merge request and posts comments.
• stack-changes: Splits a large local change into a stacked merge request chain.
• create-issue: Drafts a GitLab issue from a natural-language description.

To install one of the skills, run glab duo cli plugin install <plugin>@gitlab-duo-plugins or duo plugin install <plugin>@gitlab-duo-plugins, based on your setup.

For compatibility with the existing community plugin ecosystem, GitLab Duo CLI also reads .claude-plugin/marketplace.json files, so existing Claude Code plugin marketplaces work with GitLab Duo CLI without modification.

The GitLab Duo Agentic Chat interface in the GitLab for VS Code extension has a redesigned UI, now available as a beta. The new interface is a rebuilt version of the existing Agentic Chat panel, with the same underlying capabilities: AI models, agents, slash commands, and tool approvals.

The redesigned UI is available in GitLab 19.3 with GitLab for VS Code extension 6.87.0 and later.

To use the new UI, turn on beta and experimental features for your top-level group or instance, then reload the extension.

You can switch between the new and classic UI at any time from the panel. The beta is available for VS Code only.

You can now use get_merge_request to retrieve a merge request along with its diffs, commits, notes, pipelines, or discussions in a single call, so your AI agent no longer has to chain multiple requests to get the full picture of an MR.

You can also use the new list_merge_requests tool to search and filter merge requests by author, assignee, reviewer, state, labels, or free-text query, making it easy to find exactly the MRs you care about without leaving your workflow.

Previously, the mcp scope was hidden from the OAuth applications form in the Admin area, so you couldn’t pre-register an OAuth application for your MCP clients without using Dynamic Client Registration (DCR). Now you can create a shared OAuth application with the mcp scope directly from the Admin area, giving your users a stable client ID to reuse and helping you avoid DCR rate limits on shared networks.

Previously, when MCP clients connected to GitLab using OAuth Dynamic Client Registration (DCR), all dynamically-registered OAuth applications appeared in the Admin Area with only a generic client name, making it impossible to tell which user authorized a given application. Now, when you approve an MCP OAuth connection, your username is automatically appended to the application name — for example, [Unverified Dynamic Application] kiro — authorized by @username. You can quickly identify which user is behind each dynamic OAuth application directly from the Admin Area, without any additional configuration.

Previously, when you opened a session detail page, you had to manually expand individual activity log entries to find the agent’s current task list. Now, the session detail sidebar shows the agent’s latest plan automatically. You can view each task and its status, and a progress summary like “2 of 5 completed.” You can track what the agent is working on and how far along it is without digging through the activity log.

Mistral has deprecated the Devstral 2 model, and GitLab has deprecated Devstral 2 for GitLab Duo Agent Platform Self-Hosted. Mistral Medium 3.5 is a supported alternative available from Mistral.

If you use GitLab Self-Managed with self-hosted models, you can now use Amazon Bedrock Mantle as a supported provider. Mantle is an OpenAI-compatible inference engine for Amazon Bedrock, so you can use familiar OpenAI SDKs and integrations with Bedrock models. This feature is in beta.

In previous versions of GitLab, you couldn’t stop merges from bypassing the train. Both the option to merge immediately and the REST API could skip merge train protections without restriction. For teams running high-velocity monorepos, a single merge that skips the train can cancel and restart every in-progress pipeline, multiplying CI costs and straining infrastructure.

Now you can enforce merge train usage across the UI and API with a single project-level setting, preventing bypasses that cancel and restart in-progress pipelines. Owners and Administrators can still override the setting when needed.

Previously, MCP clients and AI tools could automatically register OAuth applications on your instance through Dynamic Client Registration (DCR), which you couldn’t turn off. This made it difficult for administrators on GitLab Self-Managed and GitLab Dedicated instances to control which OAuth clients could connect.

Now you can disable DCR entirely using the application settings API, giving you full control over which OAuth clients can access your instance. When DCR is disabled, clients must use a pre-registered OAuth application instead of registering automatically.

In previous versions of GitLab, projects using the Bun JavaScript runtime and package manager had no dependency scanning coverage.

Now, GitLab dependency scanning analyzes Bun projects by parsing bun.lock files (the text-based JSONC format introduced in Bun 1.2).

Because Bun packages are sourced from the npm registry, the GitLab advisory database already covers these dependencies with no additional configuration required. Teams using Bun as an alternative to npm, yarn, or pnpm can now scan their projects for known vulnerabilities as part of their standard CI/CD pipelines. Eligible findings are also supported by dependency scanning auto-remediation.

We’re also releasing GitLab Runner 19.3 today! GitLab Runner is the highly-scalable build agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s New

• Document Job Router version compatibility matrix
• Verify Workhorse is in the KAS to Rails request path for Job Router

Bug Fixes

• clear-docker-cache prunes all unused images when IMAGE_FILTER_FLAGS is empty
• Concrete-mode dispatch skips steps where When is unset
• PrintPodWarningEvents doesn’t work
• Custom executor fails when the .git folder is corrupt

The list of all changes is in the GitLab Runner CHANGELOG.

GitLab now fully supports Kubernetes version 1.36. To deploy your applications to Kubernetes and access all features, upgrade your connected clusters to the most recent version. For more information, see supported Kubernetes versions for GitLab features.

The Security Dashboard now includes a SAST triage and remediation funnel. This funnel shows how critical and high SAST vulnerabilities move through triage and remediation over a 30-, 60-, or 90-day window. The funnel traces each stage: detected vulnerabilities, true positives confirmed by SAST false positive detection, vulnerabilities with merge requests created by Agentic SAST Vulnerability Resolution, and vulnerabilities fixed by merged merge requests. These stages show how much of your workflow AI powers and which stages you can scale further.

You can now opt-in to using PostgreSQL 18.4 when performing a fresh install using the Linux packages.

Upgrades to PostgreSQL 18.4 for existing installations is not yet supported.

For more information, refer to the relevant documentation.

You can now set custom agents and custom flows to Restricted visibility for every group, subgroup, and project in your top-level group.

Previously, you could only set a custom flow or agent to Private (one project only) or Public (visible to everyone on GitLab.com). When you set the visibility to Restricted, the flow or agent is visible to only groups, subgroup, and projects in your top-level group. This ensures that internal logic about your custom agents and flows are not shared outside your company or organization.

GitLab Advanced SAST now supports Objective-C and Swift, bringing the same interprocedural taint analysis it delivers for other languages to iOS development. The beta is available for all GitLab Ultimate customers starting in GitLab 19.3.

The beta detects key OWASP Mobile Top 10 vulnerability classes, including insecure data storage, broken cryptography, insecure communication, and authentication and authorization flaws. When a vulnerability begins in one language and reaches a sink in the other, Advanced SAST detects the complete taint path, including paths that cross the Swift and Objective-C language boundary.

To enable, set GITLAB_ADVANCED_SAST_ENABLED: 'true' in your pipeline. If your project contains Objective-C or Swift files, the gitlab-advanced-sast-ext job runs automatically. For full setup instructions, see the Advanced SAST documentation.

Share feedback in the beta feedback issue.

In previous versions of GitLab, you had no warning when your Flex usage approached a limit. GitLab now sends billing account managers an email notification when a product reaches 50%, 80%, or 100% of its monthly reservation, and when a capped product reaches its spend cap and is cut off for the rest of the billing period. Each threshold triggers at most one email per product per billing period, so you can act on overage early without getting repeat emails for the same threshold.

On-demand usage can run up overage charges you didn’t plan for. Usage caps for GitLab Credits are now generally available: set a subscription-level cap on on-demand credits in Customers Portal, and set a default per-user cap or per-user overrides with the GraphQL API. When consumption reaches a cap, features that consume GitLab Credits, like GitLab Duo Agent Platform, are suspended until the next billing period begins or an administrator adjusts the cap. Usage caps were introduced in GitLab 18.11 behind the budget_caps_graphql_api feature flag. In GitLab 19.3, the feature flag is removed.

With GitLab Flex, overage from one capability draws down the same commitment every other capability depends on. You can now set a spend cap for each capability when you adjust your Flex reservation in the Customers Portal: Restricted (no overage past the reservation), Usage cap (a bounded amount of overage), or Unlimited (unlimited overage past the reservation). When a capped capability reaches its cap, its usage stops for the rest of the billing period, and capabilities without a cap keep running.