On June 18, 2026, GitLab 19.1 was released with the following features.
We’d also like to announce this month’s Notable Contributor: Pishel65! We are excited to recognize Pishel65, a Level 3 contributor with 19 merged MRs and 9 more open since joining in October 2025.
Secret false positive detection with the GitLab Duo Agent Platform is now generally available.
Security teams spend significant time investigating secret detection findings that are incorrectly flagged as actual secrets. These false positives create alert fatigue, erode trust in scan results, and divert attention from genuine security risks.
When a security scan runs, GitLab Duo automatically analyzes each critical and high severity secret detection vulnerability to determine if it is a false positive. The AI assessment appears in the vulnerability report, so you have immediate context for faster and more confident triage decisions.
Key features include:
We welcome your feedback in issue 592861. Administrators can now set GitLab Duo to be always on for all projects in an entire instance or top-level group. When GitLab Duo is set to always on, group, subgroup, and project owners cannot turn off GitLab Duo, giving enterprises centralized AI governance for compliance and regulated environments.
This new setting is symmetrical to the existing always off setting, closing a gap where GitLab Duo could be locked off but could not be locked on. This new setting is especially valuable for organizations with autonomous divisions or subsidiaries that need to guarantee consistent AI tooling across the business.
To set GitLab Duo to be always on, go the instance or top-level group GitLab Duo settings and set GitLab Duo availability to Always on.
Previously, you needed to select reviewers for each merge request manually,
even when a CODEOWNERS
file already defined who should review each file.
You can now configure a project to assign Code Owners as reviewers automatically. GitLab assigns every Code Owner that matches the changed files. This happens when a merge request is created in a ready state, or when a draft is marked ready. If you already assigned a reviewer, GitLab skips automatic assignment and keeps your choice.
To turn on automatic reviewer assignment, go to Settings > Merge requests > Automatic reviewer assignment and select Automatically assign all code owners as reviewers.
You can now create compliance frameworks from predefined templates.
Previously, building a compliance framework required defining every requirement and control by hand, a repetitive process when a framework had dozens of controls.
Now, when you create a new framework in the Compliance center, you can:
19 templates are available, including ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, TISAX, and more.
In GitLab versions earlier than 19.1, you couldn’t trust a feature branch pipeline to surface every secret in your branch. A new branch scanned only the latest commit. An existing branch scanned only your most recent push. A credential leaked in an earlier commit could sit undetected, reaching shared branches or production before being flagged.
Now you can catch those secrets where they’re cheapest to fix. In GitLab 19.1, secret detection scans every commit from the branch’s divergence point with the default branch to the latest commit. That means fewer secrets slip through to later stages, less time rotating exposed credentials after the fact, and consistent, predictable coverage across your branches.
Administrators can now configure tool-level approval policies for GitLab Duo agents, gating sensitive actions with human approval at the moment of execution.
Previously, after an AI agent was approved for a project, it could invoke any of its tools without further review, including write and destructive operations. Now, you can define rules for groups and projects that map each tool to one of three modes:
When an AI agent calls a tool in “ask” mode, the user is prompted with an inline approval card before execution proceeds.
This beta release includes Agentic Chat, IDE, and flows, and emits audit events for every approval decision.
Administrators and top-level group Owners can now control which AI agents and flows are available within their organization. They can:
The AI Catalog now validates your custom flow configuration before saving or triggering it.
Previously, syntax errors and misconfigured parameters in a custom flow (for example, missing inputs or unknown tool parameters) only surfaced at runtime, after a CI job had already started. This made debugging slow and difficult.
Now, when you save or update a custom flow in the AI Catalog, GitLab checks the configuration upfront and surfaces any errors directly in the UI. Valid flows are unaffected and continue to save and trigger as usual.
Previously, when Agentic Chat asked you to approve a tool invocation, you could approve it once or approve the tool call with these arguments for the remainder of the session. Different arguments would require additional approval.
Workflows that repeated similar
commands, such as a series of git
operations, forced you through a stream of nearly identical prompts.
You can now choose a third approval option, Approve all uses of this tool for session. This option approves invocations of the tool for the remainder of the session whenever the arguments match the approved pattern.
Pattern-based approvals are available for Agentic Chat in the GitLab UI, GitLab Duo CLI, GitLab for VS Code, and the GitLab Duo plugin for JetBrains IDEs.
Automatic reviews in Code Review Flow are now turned on by default for new GitLab Duo trial customers on GitLab.com, so you can start getting AI-powered feedback on your merge requests from day one — without any manual setup.
With a new flat pricing model, you get immediate value from smarter, faster code reviews right out of the box. If needed, you can opt out in your group settings.
GitLab Duo health checks now include foundational flows readiness checks, which verify:
gitlab--duo
tag is registered and
connected, and uses a Docker-compatible executor.In previous versions of GitLab, Code Review Flow supported only Anthropic Claude models. Teams that could not use Anthropic models due to contractual, policy, or procurement constraints had no way to run Code Review Flow.
You can now select GPT-5.2 or GPT-5.3 Codex as the model for Code Review Flow. Top-level group Owners can switch the model for Agentic Code Review in Settings > GitLab Duo > Configure features, under GitLab Duo Agent Platform. The GPT models are hosted through the GitLab AI Gateway, so no additional configuration is required.
Both models passed benchmark evaluation against the GitLab Duo code review dataset, with review quality comparable to the default Claude Sonnet 4.6 Vertex model. See the
[code review benchmark](https://duo-review-bench-6f7260.gitlab.io/) for results.
For GitLab Duo Agentic Chat, you can now configure an allowlist of approved models, and set an organization-wide default, if you are:
This gives organizations control over which models users can select when using Agentic Chat.
In previous versions of GitLab, you could only run flows and external agents when the service account was mentioned, assigned, or added as a reviewer. Coordinating automation around the rest of the merge request lifecycle, or around work item creation, required external glue.
You can now configure triggers for four additional events:
To configure a trigger, go to AI > Triggers in your project, or select one when you enable a flow.
You can now use the Scanner Enablement Wizard to close scanner coverage gaps across your projects without manually identifying which projects need attention.
Security configuration profiles define which scanners run and how. Security inventory shows scanner coverage across your projects and lets you bulk-apply profiles to selected projects or subgroups. The wizard adds a goal-driven workflow on top: you set the goal, and it finds the projects missing coverage and closes only those gaps.
By default, OAuth access tokens in GitLab expire after two hours. In GitLab 19.1, instance administrators on GitLab Self-Managed and GitLab Dedicated can set a custom lifetime for new OAuth access tokens. You can configure any value from 300 to 7200 seconds. This helps you enforce shorter-lived tokens for security-sensitive OAuth integrations, including MCP clients, without changing the behavior of existing tokens.
You can now add emoji reactions directly to wiki pages in both project and group wikis.
Use the GitLab emoji picker to react to page content. Each page shows reaction counts and who reacted. Reactions persist across page edits and versions. Scheduled pipeline execution policies are now available as a beta feature and no longer require an experiment flag to enable. You can enforce custom CI/CD jobs on a daily, weekly, or monthly cadence across your projects, independent of commit activity. Use scheduled policies to run compliance scripts, security scans, or dependency checks on repositories that may not have regular code changes.
Scheduled policies now enforce variable precedence consistently with regular pipeline execution policies. Each security policy project supports up to five scheduled policies, and GitLab automatically cancels running pipelines when a policy is disabled or deleted. Configure schedules in YAML or the UI, with time zone support, time window distribution, branch targeting, and snooze functionality.
The Security Manager role is now generally available, providing comprehensive access to security features including vulnerability management, security dashboards, policy configuration, and compliance tools. Security teams no longer need the Developer role or the Maintainer role to access security features, eliminating over-privileging concerns while maintaining separation of duties.
Users with the Security Manager role have the following access:
To get started, go to a group and select Manage > Members to invite and assign members to the Security Manager role.
You can now use security findings from any SARIF 2.1.0-compliant scanner with GitLab vulnerability management.
Define a CI/CD job that runs your scanner and outputs a SARIF artifact. GitLab parses, validates, and imports those findings into your security workflows. Results appear alongside GitLab native scanner output in the pipeline security tab, the vulnerability report, the security dashboard, the merge request security widget, and security policies. This feature gives security teams a single, consolidated view of vulnerabilities regardless of which tool produced them.
GitLab assigns each finding a report type based on its identifiers, mapping results into categories such as SAST
, dependency scanning
, and secret detection
. Supported scanners include Semgrep and Checkmarx for SAST, Trivy and Snyk for dependency and container scanning, and Gitleaks for secret detection.
Wiki pages now appear in your recently viewed items, so you can return to pages you visit often.
On the GitLab homepage, the Quick access widget lists recently viewed project and group wiki pages, alongside issues, merge requests, and epics. GitLab automatically removes pages that are deleted or that you can no longer access.
In GitLab 19.1, the vulnerability results details page uses consistent, descriptive, and security industry-standard terminology for scan results:
In GitLab 18.10, audit logs began capturing the specific Git operation performed (clone, pull, fetch, or push) for human users.
In GitLab 19.1, this extended to all actor types, including runners using deploy tokens and SSH certificate users. Audit logs now reflect a complete picture of all Git activity across your repositories, regardless of who or what initiated it.
Previously, viewing blame information required navigating to a separate page, breaking your flow when reviewing code.
You can now toggle blame information directly in the file view. Each line shows who last modified it, and you can hover for a commit popover with additional details. Select View blame prior to this change to trace history further, or select Ignore specific revisions to exclude specific commits from the blame view.
Previously, the repository commit list had limited filtering, making it harder to find specific commits in long histories.
The redesigned commit list includes:
Previously, when you split a large change into smaller merge requests that build on each other, the UI gave no signal that they were related. Authors and reviewers had to track the sequence manually.
GitLab now detects stacked merge requests automatically and shows them in the merge request header. A merge request joins a stack when it targets another open merge request’s source branch, or when another open merge request targets its source branch. The stack control next to the source branch shows the current position (for example, 1 of 2) and lets you jump to any other merge request in the stack.
To create stacked merge requests from the command line, use stacked diffs in the GitLab CLI.
You can now stream AI audit events to external destinations through the GitLab audit event streaming infrastructure, giving security and compliance teams real-time visibility into LLM and AI interactions.
With AI audit event streaming enabled, GitLab forwards these events to any active instance streaming destination, including your SIEM (Security Information and Event Management), alongside other audit events.