On September 17, 2026, GitLab 19.4 was released with the following features.
We are excited to recognize Jimmy, a Level 4 contributor, as this month’s Notable Contributor!
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 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.
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 down the 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: , 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.
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 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 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 and the Gitleaks-based analyzer.
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.
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,
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 in merge request approval policies.
You don’t need any additional setup. Coverage applies to the supported package types: npm, PyPI, Maven, Go, NuGet, Cargo, and RubyGems. The same advisories power continuous vulnerability scanning, and offline instances download them manually.
Share feedback on issue 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 and
fetches from large repositories.
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 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 for these contributions (MR 1 MR 2 MR 3 MR 4)!
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 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.