GitLab 19.4 release notes

GitLab released version 19.4 on September 17, 2026, adding governance controls for GitLab MCP server tools so administrators can allow or deny third-party agent access from the same group and project GitLab Duo settings used for internal Duo Agent Platform tools. The release also extends Advanced SAST to Kotlin, Dart, and Scala, adds SPDX license expressions such as 'MIT OR Apache-2.0' to license data and approval policies, and introduces a /goal slash command in GitLab Duo CLI 9.17.0 and later that delegates open-ended objectives to a locally run, goal-driven flow with an independent judge. The MCP tool governance feature is in beta, with feedback directed to issue #628378.

On September 17, 2026, GitLab 19.4 was released with the following features. We are excited to recognize Jimmy https://gitlab.com/jspagnola , a Level 4 contributor, as this month’s Notable Contributor https://contributors.gitlab.com/notable-contributors Jimmy contributed across the GitLab codebase, client-go , and the Terraform provider to ensure that tokens, service accounts, and push mirrors can be managed end to end through infrastructure as code. Previously, you could only apply AI agent tool governance https://docs.gitlab.com/user/ai-governance/tool-governance/ rules to internal GitLab Duo Agent Platform tools. Tools available to both GitLab Duo Agent Platform and third-party agents through the GitLab MCP server followed fixed rules that could not be changed. You can now govern GitLab MCP server tools from the same place as internal GitLab Duo Agent Platform tools. They appear alongside internal tools in your group and project GitLab Duo settings, where you can set a mode for each tool: You can now restrict access to MCP Model Context Protocol servers by allowing or denying access to: This feature gives you assurance that AI agents within Duo Agent Platform are operating within governed boundaries and can only access MCP tools that are within their scope to perform their activities, sessions, and tasks. These controls apply consistently wherever AI agents run, including: This feature is currently in beta and we welcome your feedback in issue 628378 https://gitlab.com/gitlab-org/gitlab/-/issues/628378 . Use the Vulnerability Context Flow to produce context to triage vulnerabilities more efficiently and intelligently. The flow produces context in the following three categories: Advanced SAST now scans Kotlin, Dart, and Scala codebases with the same deep taint analysis that covers Java, Python, and other supported languages, all delivered through the Software Factory architecture with per-language front-ends and framework-aware rule gating. All three additions are verified using deliberately vulnerable real-code repositories, with findings reported as code flows from source to sink. GitLab license data now carries SPDX license expressions, including compound declarations such as MIT OR Apache-2.0 or GPL-2.0-only WITH Classpath-exception-2.0 . Previously these were reported as unknown in the dependency list and were invisible to license approval policies. Composite licenses now appear in the dependency list with their operator AND , OR , WITH , and license approval policies can allow or deny them the same way they handle single-license dependencies. Expressions declared in a CycloneDX SBOM have been supported since GitLab 19.3. This release adds them to the license data GitLab synchronizes. Offline instances receive expressions only after downloading the v3 license data https://docs.gitlab.com/topics/offline/quick start guide/ download-v3-license-data . GitLab Duo CLI now includes a /goal slash command that delegates open-ended objectives to a governed, goal-driven flow that runs locally. You describe a goal and GitLab Duo handles implementation and verification, using an independent judge to decide when you have achieved your goal or reached the iteration limit. You stay in control the whole time: pause, update the goal, or redirect the agent at any time. The /goal slash command requires GitLab 19.3 and later, and GitLab Duo CLI 9.17.0 and later. To get started, run /goal <task . For example: /goal Fix the failing tests in spec/models/user spec.rb You can now invoke GitLab Duo agent flows directly from Slack, without switching to the GitLab UI. With the GitLab Duo Slack integration, you can mention GitLab with @GitLab in any Slack channel or thread. Mention GitLab to trigger agent flows, get answers from your codebase, and create GitLab issues from conversations. GitLab Duo streams its progress back into the Slack thread in real time, and includes thumbs-up and thumbs-down feedback buttons so you can rate responses without leaving Slack. This integration is available as an experiment. To share your feedback, add a comment to issue 624364 https://gitlab.com/gitlab-org/gitlab/-/work items/624364 . Build custom flows for your GitLab projects with the GitLab flow builder, a new visual editor for AI-native workflows in the GitLab for VS Code extension. Compose a flow visually from components Agent, Custom tool, and AI task , or edit the underlying YAML directly. To start, open your flow’s YAML file in VS Code and select Open GitLab Flow Builder . Test your flow with the Run button, which opens an execution console. When your flow is ready, select Publish to publish it to the AI Catalog. The flow builder is available as a beta feature in GitLab for VS Code 6.87.0 and later. To get started, enable the gitlab.featureFlags.flowBuilder setting in VS Code. New CI/CD tools let agents trigger, inspect, and control CI/CD from any MCP client: save pipeline runs, retries, or cancels a pipeline without switching tools. get job returns job metadata together with the job trace, so an agent can read the log of a failed build and diagnose the problem on its own. Previously, agents had no way to trigger or inspect pipelines through MCP. Merge request tools let agents run the full merge request loop through the GitLab MCP server: save merge request opens and updates an MR. get merge request inspects an MR in depth, with new diffs, conflicts, and approvals facets. save merge request review leaves line-level review comments, with batched diff comments and a summary in a single call. accept merge request merges an MR once checks pass, and can also approve or unapprove it. New project and user tools give agents the context they need to target work correctly through the GitLab MCP server: list projects finds and reads project details. get user looks up user details for assignment and mentions. Previously, agents had no way to discover project or user information through the GitLab MCP server. New repository tools let agents browse a project’s structure, read its commit history, and propose changes through the GitLab MCP server: list repository tree explores the file tree. list tags enumerates refs. list releases inspects published releases. get commit retrieves a commit’s metadata, diff, or notes. list commits pages through a branch’s history. add commit commits one or more file actions in a single call, optionally to a new branch from a specific starting ref or source project. fork repository forks a project, so an agent can go from exploring an upstream repository to proposing changes without leaving its client. semantic code search is now semantic search . The tool finds code by meaning rather than by exact symbol or filename, which is unchanged from earlier releases. The rename adds a scope parameter so that additional indexed content types can fold into the same tool in future releases. Today scope accepts code only. Thank you to arun kumar https://gitlab.com/arunsdev for this contribution The GitLab MCP server now exposes work item tools, so agents and MCP clients can search, read, create, and update issues, epics, tasks, incidents, objectives, and key results. Use get work item to read a single item in depth, list work items to search across a group or project, and save work item to create or update any work item type. Because issues and epics are work item types, get work item and save work item cover what get issue and create issue do today. save note lets an agent comment on a work item or merge request and reply inside an existing discussion thread. The introduction of this tool renames existing create merge request note and create workitem note . In previous versions of GitLab, the Merge request trigger event type only supported the Approved , Marked ready , and Merge conflict actions. You had no way to run a flow or external agent the moment someone opened a merge request without using a tool outside GitLab. You can now select Created as a trigger action. When someone opens a merge request in draft or ready state, and GitLab generates the diff, your flow or external agent runs. Use this for a first-pass review, or to add context from related issues. To configure this trigger, go to AI Triggers in your project, or select it when you enable a flow. Finding the details that matter about an agent session used to mean hunting through a cluttered panel. Now, the session details panel surfaces what you need at a glance: status, timestamps, and the triggering user appear in an overview bar, while the right rail organizes identity, execution, and supplemental details into clearly labeled groups. A new Linked items section separates what started the session from what it produced, including merge requests, work items, jobs, and comments. In the GitLab Duo side panel, session details now live in a collapsible bar pinned to the bottom, so they stay accessible without getting in your way. The GitLab Duo Agent Platform now supports independent model selection for the Developer Flow. As an administrator, you can select a specific AI model for the Developer Flow separately from other GitLab Duo Agent Platform features, giving teams greater control over model selection. The GitLab Duo Agent Platform now supports three open-weight models: GLM 5.3, Kimi K3, and MiniMax M3. In GitLab Duo Agentic Chat, you can select any of these models for your own conversations. Users with the Owner role for a group and administrators can also set them as the default for Agentic Chat and for other agents, flows, and features. In previous versions of GitLab, the only way to stop a trigger from automatically starting a flow was to delete it entirely. Deleting a trigger meant losing any complex filter configuration you had set up. Now you can turn a flow trigger off and retain its configuration. Use the new toggle to turn it back on at any time. To manage triggers, go to AI Triggers . In previous versions of GitLab, you turned on SAST false positive detection, GitLab Duo Vulnerability Resolution, secret detection false positive detection, and dependency scanning auto-remediation for each project individually. Now you can apply an Automated Triage and Remediation profile to a group or project, setting severities and run modes in one action. Start with a preset, or configure each flow yourself: Profiles are available only with the GraphQL API, and require GitLab Duo Agent Platform with foundational flows turned on for the top-level group. Most flows consume GitLab Credits. When a file is locked, you now see who locked it and what your options are, without leaving the blob viewer. Previously, only a Locked label appeared, with no way to tell who locked the file or whether you could unlock it yourself. Now, a popover next to the label shows who locked it. If you have permission to unlock the file, the popover includes an unlock action. If you don’t, it explains why. For locked directories, the popover links you directly to the specific file that’s blocking your changes. Security teams can use the bulkSetVulnerabilityFindingsDueDates GraphQL mutation to assign, update, or remove due dates for vulnerability findings in bulk. Each request supports up to 1,000 finding UUIDs and returns counts for assigned, removed, and skipped updates, along with structured errors. Teams can use this information to connect vulnerability remediation timelines with existing service-level agreement SLA and workflow automation. You can now view scanner coverage for an entire group hierarchy from one page. In previous versions of GitLab, the Security Inventory https://docs.gitlab.com/user/application security/security inventory/ showed coverage per subgroup, but no total for the entire group. A coverage widget now aggregates scanner coverage across every project in the group and its subgroups, and shows the percentage and number of projects where each scanner is enabled, not enabled, failing, or stale. To focus on one scanner, such as SAST or Dependency Scanning, use the scanner dropdown list. Then select a status to filter the project list, and turn on scanners for the projects that aren’t covered. The Security Inventory also now lets you control which columns are shown. To show or hide the Vulnerabilities , Tool coverage , and Security attributes columns, select Display . When secret detection finds a leaked GitLab personal access token in a public project, automatic response revokes it. In GitLab versions earlier than 19.4, revocation used only one detection rule and revoked only the legacy token format. Tokens created on GitLab 18.3 and later use the routable or versioned routable format. GitLab detected and reported these tokens without revoking them. In GitLab 19.4 and later, revocation recognizes all three GitLab personal access token detection rules: gitlab personal access token gitlab personal access token routable gitlab personal access token routable versioned Revocation also covers findings from GitLab Secret Scanning for Source Code https://docs.gitlab.com/user/application security/secret detection/gitlab secret scanner/ and the Gitleaks-based analyzer https://docs.gitlab.com/user/application security/secret detection/pipeline/ . You do not need to change any configuration. Instances with automatic response enabled get this wider coverage immediately. We’re also releasing GitLab Runner 19.4 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 Bug Fixes The list of all changes is in the GitLab Runner CHANGELOG https://gitlab.com/gitlab-org/gitlab-runner/blob/19-4-stable/CHANGELOG.md . Previously, pasting a copied table into a table cell always merged the copied cells into the existing table, which made it difficult to create a nested table. Now you can choose how a pasted table behaves: You can also use a keyboard shortcut to paste a table into a cell as a nested table: Command + Option + V on macOS, or Control + Alt + V on Windows and Linux. Standard paste with Control + V or Command + V works as it did before. In previous versions of GitLab, Dependency Scanning only surfaced packages with known CVEs. Malicious packages, those crafted to harm through typosquatting, compromised maintainer accounts, or embedded malware, produced no findings. GitLab 19.4 introduces malicious package detection in beta. Dependency Scanning now checks your dependencies against GitLab malware advisories https://docs.gitlab.com/user/application security/gitlab advisory database/ gitlab-malware-advisories , so threats can surface before they are widely known. Findings appear in your Dependency List and Vulnerability Report with a red Malware badge, always Critical severity, identified by a GLAM- ID, not a CVE. You can also block malicious packages before they merge, using the malware rule https://docs.gitlab.com/user/application security/policies/merge request approval policies/ block-malicious-packages-with-the-malware-rule in merge request approval policies. You don’t need any additional setup. Coverage applies to the supported package types https://docs.gitlab.com/user/application security/gitlab advisory database/ supported-package-types : npm, PyPI, Maven, Go, NuGet, Cargo, and RubyGems. The same advisories power continuous vulnerability scanning https://docs.gitlab.com/user/application security/continuous vulnerability scanning/ malicious-packages , and offline instances https://docs.gitlab.com/topics/offline/quick start guide/ download them manually. Share feedback on issue 606036 https://gitlab.com/gitlab-org/gitlab/-/work items/606036 . Security dashboards are now available at the organization level. Users can see the following data across all top-level groups in an organization: In GitLab 19.4, the GitLab MCP server provides the following new tools for vulnerability management: list vulnerabilities , which lists security vulnerabilities in a GitLab project with optional filtering by severity and report type, with cursor pagination. get vulnerability , which fetches full details for a single vulnerability by numeric ID, converting it to the gid://gitlab/Vulnerability/<id global ID format. save vulnerability , which covers five write operations on GitLab vulnerabilities in a single consolidated tool: These new vulnerability management tools allow AI agents to run vulnerability triage and remediation actions through the GitLab MCP server. GitLab 19.3 introduced email notifications for reservation thresholds and for the moment a capped capability is cut off. The spend cap itself had no early warning, so the first email about a cap arrived when usage had already stopped. GitLab now emails billing account managers when a capability’s on-demand usage reaches 50% or 80% of its monthly spend cap, naming the capability and the cap in credits. Only the highest threshold crossed is sent, at most once per capability per billing period. Caps of less than $10 are skipped, so a small cap does not generate noise. Geo SSH proxying enabled by default The following feature flags are enabled by default in GitLab 19.4: geo proxy fetch ssh to primary geo proxy push ssh to primary Geo SSH proxying provides a more reliable path for SSH fetches and pushes to a Geo secondary site when the operation is proxied to the primary site. It also resolves long-standing bugs where proxied operations failed, such as pushes with push options https://gitlab.com/gitlab-org/gitlab/-/issues/417186 and fetches from large repositories https://gitlab.com/gitlab-org/gitlab/-/issues/454707 . Action required for Cloud Native GitLab deployments Cloud Native GitLab deployments using the bundled NGINX Ingress must either: Otherwise, SSH fetches and pushes through Geo secondaries may hang or time out. See the Geo troubleshooting documentation https://docs.gitlab.com/administration/geo/replication/troubleshooting/ssh proxying/ for SSH proxying for more information. When a subscription had temporary evaluation credits, all usage drew from that shared pool first. Every user’s included monthly credits sat idle until the evaluation pool ran out, and then reset at the end of the month. GitLab now consumes each user’s included credits first, and draws from the shared pool of temporary evaluation credits only after a user has used their included amount. The Monthly Commitment Pool, One-Time Charge credits, and On-Demand credits are consumed in the same order as before, so your bill is unaffected. The credit usage export gave you one row per day, which told you how much a subscription spent but not what it spent on. Attributing credits to a team, a project, or a single automation meant guesswork. The export now returns a ZIP file with two CSV files: the daily summary you already had, and a per-event file with one row for each billable event. Each row includes the product, flow type, session, user, namespace, project, credits used, and token counts. Exports run in the background, and GitLab emails you a download link when the file is ready. Credit caps limit how many GitLab Credits each user can consume, but until now you could only configure them through the GraphQL API. Setting a different cap for a handful of users meant writing mutations by hand. The new Credit caps page lets you set the flat cap that applies to every user by default, and add per-user overrides for individual users through a searchable picker. This page is available in GitLab Credits for group Owners on GitLab.com and administrators on GitLab Self-Managed. The GraphQL mutations still work if you prefer to script cap changes. When an LDAP group sync fails, the reason now reaches you. The failure is recorded against the group, the members that caused it are named up to five , and a danger alert appears on the group members page, so a sync blocked by an email-domain restriction is diagnosable from the UI. A new group filter setting lets you narrow which LDAP entries count as groups. The audit log also distinguishes causes that previously shared one entry: LDAP group links created and removed, and users blocked by LDAP sync, each now get their own audit event type. Thank you to Sergey Pechenko https://gitlab.com/tnt4brain for these contributions MR 1 https://gitlab.com/gitlab-org/gitlab/-/merge requests/250622 MR 2 https://gitlab.com/gitlab-org/gitlab/-/merge requests/253816 MR 3 https://gitlab.com/gitlab-org/gitlab/-/merge requests/252957 MR 4 https://gitlab.com/gitlab-org/gitlab/-/merge requests/247146 While GitLab checks a merge request, the widget now tells you. Merge conflicts must be resolved becomes Checking for merge conflicts until the check finishes. When a rebase is refused, you see the specific reason, such as Source branch is protected from force push , instead of a generic retry prompt. You can act on the current state of the merge request. The sticky title bar that stays visible while scrolling a merge request now also updates immediately when you mark it draft or ready, instead of requiring a page refresh. Thank you to the following users for these contributions Community contributors added new tools for the GitLab MCP server. Agents can now use get project and list project members to read project metadata and members, list branches to list a repository’s branches, and list merge requests to list merge requests across a whole group. get duo session fetches a GitLab Duo session so you can see what an earlier run did. These tools ship alongside the other new GitLab MCP server tools in 19.4 and run under the same tool governance, so an agent using them follows the rules your team already set. The new file page now has Write and Preview tabs, the same pair the edit page has had for years, so you can see how a Markdown or AsciiDoc file renders before its first commit exists. Preview keeps up with your edits: rename a file from .txt to .md mid-edit and the preview switches renderer; rename it away from Markdown and the live preview stops. Snippets also gained Markdown live preview, available from the editor’s right-click menu. Thank you to skkzsh https://gitlab.com/skkzsh for this contribution Other improvements in this release include: GET /projects/:id/jobs/:job id/artifacts?file type=junit for a JUnit file. Dependency-Scanning.v2 template. Other additions to the interface in this release include: /internal note marks a comment internal as you create it, so internal notes can live inside comment templates and saved replies. /type Epic promotes an issue to an epic, the same as /promote to Epic .