{"slug": "gitlab-19-4-release-notes", "title": "GitLab 19.4 release notes", "summary": "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.", "body_md": "On September 17, 2026, GitLab 19.4 was released with the following features.\n\nWe are excited to recognize [Jimmy](https://gitlab.com/jspagnola), a Level 4 contributor,\nas this month’s [Notable Contributor](https://contributors.gitlab.com/notable-contributors)!\n\nJimmy contributed across the GitLab codebase, `client-go`, and the Terraform\nprovider to ensure that tokens, service accounts, and push mirrors can be\nmanaged end to end through infrastructure as code.\n\nPreviously, you could only apply [AI agent tool governance](https://docs.gitlab.com/user/ai-governance/tool-governance/)\nrules to internal GitLab Duo Agent Platform tools. Tools available to both GitLab Duo Agent Platform and\nthird-party agents through the GitLab MCP server followed fixed rules that could not be changed.\n\nYou can now govern GitLab MCP server tools from the same place as internal GitLab Duo Agent Platform\ntools. They appear alongside internal tools in your group and project **GitLab Duo** settings, where\nyou can set a mode for each tool:\n\nYou can now restrict access to MCP (Model Context Protocol) servers by allowing or denying access to:\n\nThis 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.\n\nThese controls apply consistently wherever AI agents run, including:\n\nThis feature is currently in beta and we welcome your feedback in [issue #628378](https://gitlab.com/gitlab-org/gitlab/-/issues/628378).\n\nUse the Vulnerability Context Flow to produce context to triage vulnerabilities more efficiently and intelligently.\n\nThe flow produces context in the following three categories:\n\nAdvanced 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.\n\nAll three additions are verified using deliberately vulnerable real-code repositories, with findings reported as code flows from source to sink.\n\nGitLab license data now carries SPDX license expressions, including compound declarations\nsuch as `MIT OR Apache-2.0` or `GPL-2.0-only WITH Classpath-exception-2.0`.\nPreviously these were reported as `unknown` in the dependency list and were invisible to\nlicense approval policies.\n\nComposite licenses now appear in the dependency list with their operator (`AND`, `OR`,\n`WITH`), and license approval policies can allow or deny them the same way they handle\nsingle-license dependencies.\n\nExpressions declared in a CycloneDX SBOM have been supported since GitLab 19.3.\nThis release adds them to the license data GitLab synchronizes.\nOffline instances receive expressions only after\n[downloading the v3 license data](https://docs.gitlab.com/topics/offline/quick_start_guide/#download-v3-license-data).\n\nGitLab Duo CLI now includes a `/goal` slash command that delegates open-ended objectives to a\ngoverned, goal-driven flow that runs locally.\n\nYou 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.\n\nThe `/goal` slash command requires GitLab 19.3 and later, and GitLab Duo CLI 9.17.0 and later.\n\nTo get started, run `/goal <task>`.\n\nFor example:\n\n```\n/goal Fix the failing tests in spec/models/user_spec.rb\n```\n\nYou can now invoke GitLab Duo agent flows directly from Slack, without switching to the GitLab UI.\n\nWith 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.\n\nThis 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).\n\nBuild 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.\n\nTo start, open your flow’s YAML file in VS Code and select **Open GitLab Flow Builder**.\nTest your flow with the **Run** button, which opens an execution console.\nWhen your flow is ready, select **Publish** to publish it to the AI Catalog.\n\nThe 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.\n\nNew CI/CD tools let agents trigger, inspect, and control CI/CD from any MCP client:\n\n`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\nread the log of a failed build and diagnose the problem on its own.\nPreviously, agents had no way to trigger or inspect pipelines through MCP.\n\nMerge request tools let agents run the full merge request loop through the GitLab MCP server:\n\n`save_merge_request` opens and updates an MR.`get_merge_request` inspects an MR in depth, with new diffs, conflicts, and\napprovals facets.`save_merge_request_review` leaves line-level review comments, with batched\ndiff comments and a summary in a single call.`accept_merge_request` merges an MR once checks pass, and can also approve\nor unapprove it.\nNew project and user tools give agents the context they need to target work correctly through the GitLab MCP server:\n\n`list_projects` finds and reads project details.`get_user` looks up user details for assignment and mentions.\nPreviously, agents had no way to discover project or user information through the GitLab MCP server.\n\nNew repository tools let agents browse a project’s structure, read its commit history, and propose changes through the GitLab MCP server:\n\n`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\nnew branch from a specific starting ref or source project.`fork_repository` forks a project, so an agent can go from exploring an\nupstream repository to proposing changes without leaving its client.\n`semantic_code_search` is now `semantic_search`. The tool finds code by meaning\nrather than by exact symbol or filename, which is unchanged from earlier\nreleases. The rename adds a `scope` parameter so that additional indexed content\ntypes can fold into the same tool in future releases. Today `scope` accepts\n`code` only.\n\nThank you to [arun kumar](https://gitlab.com/arunsdev) for this contribution!\n\nThe 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.\n\nUse `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.\n\nBecause issues and epics are work item types, `get_work_item` and `save_work_item` cover what `get_issue` and `create_issue` do today.\n\n`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`.\n\nIn 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.\n\nYou 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.\n\nTo configure this trigger, go to **AI > Triggers** in your project, or select it when you enable a flow.\n\nFinding 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.\n\nA new **Linked items** section separates what started the session from what it produced, including\nmerge requests, work items, jobs, and comments. In the GitLab Duo side panel, session details now\nlive in a collapsible bar pinned to the bottom, so they stay accessible without getting in your way.\n\nThe 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.\n\nThe GitLab Duo Agent Platform now supports three open-weight models: GLM 5.3, Kimi K3, and MiniMax M3.\n\nIn 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.\n\nIn 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.\n\nNow you can turn a flow trigger off and retain its configuration. Use the new toggle to turn it back on at any time.\n\nTo manage triggers, go to **AI** > **Triggers**.\n\nIn 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:\n\nProfiles 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.\n\nWhen a file is locked, you now see who locked it and what your options are, without leaving the blob viewer.\n\nPreviously, only a **Locked** label appeared, with no way to tell who locked the\nfile or whether you could unlock it yourself. Now, a popover next to the label\nshows who locked it. If you have permission to unlock the file, the popover\nincludes an unlock action. If you don’t, it explains why. For locked\ndirectories, the popover links you directly to the specific file that’s\nblocking your changes.\n\nSecurity teams can use the `bulkSetVulnerabilityFindingsDueDates`\nGraphQL mutation to assign, update, or remove due dates for\nvulnerability findings in bulk. Each request supports up to\n1,000 finding UUIDs and returns counts for assigned,\nremoved, and skipped updates, along with structured\nerrors. Teams can use this information to\nconnect vulnerability remediation\ntimelines with existing service-level agreement (SLA) and workflow automation.\n\nYou can now view scanner coverage for an entire group hierarchy from one page. In previous\nversions of GitLab, the [Security Inventory](https://docs.gitlab.com/user/application_security/security_inventory/)\nshowed coverage per subgroup, but no total for the entire group. A coverage widget now aggregates\nscanner coverage across every project in the group and its subgroups, and shows the\npercentage and number of projects where each scanner is enabled, not enabled, failing, or\nstale. To focus on one scanner, such as SAST or Dependency Scanning, use the scanner dropdown list.\nThen select a status to filter the project list, and turn on scanners for the projects that aren’t\ncovered.\n\nThe Security Inventory also now lets you control which columns are shown. To show or hide the\n**Vulnerabilities**, **Tool coverage**, and **Security attributes** columns, select **Display**.\n\nWhen 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.\n\nIn GitLab 19.4 and later, revocation recognizes all three GitLab personal access token detection rules:\n\n`gitlab_personal_access_token`` gitlab_personal_access_token_routable``gitlab_personal_access_token_routable_versioned`\nRevocation 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/).\nYou do not need to change any configuration.\nInstances with automatic response enabled get this wider coverage immediately.\n\nWe’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.\n\n**What’s New**\n\n**Bug Fixes**\n\nThe list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/19-4-stable/CHANGELOG.md).\n\nPreviously, 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.\n\nNow you can choose how a pasted table behaves:\n\nYou 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.\n\nStandard paste with `Control`+` V` or `Command`+` V` works as it did before.\n\nIn 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.\n\nGitLab 19.4 introduces malicious package detection in beta. Dependency Scanning now checks\nyour dependencies against [GitLab malware advisories](https://docs.gitlab.com/user/application_security/gitlab_advisory_database/#gitlab-malware-advisories),\nso threats can surface before they are widely known. Findings appear in your Dependency List\nand Vulnerability Report with a red **Malware** badge, always Critical severity, identified\nby a `GLAM-` ID, not a CVE.\n\nYou can also block malicious packages before they merge, using the\n[malware rule](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/#block-malicious-packages-with-the-malware-rule)\nin merge request approval policies.\n\nYou don’t need any additional setup. Coverage applies to the\n[supported package types](https://docs.gitlab.com/user/application_security/gitlab_advisory_database/#supported-package-types):\nnpm, PyPI, Maven, Go, NuGet, Cargo, and RubyGems. The same advisories power\n[continuous vulnerability scanning](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/#malicious-packages),\nand [offline instances](https://docs.gitlab.com/topics/offline/quick_start_guide/) download them manually.\n\nShare feedback on [issue 606036](https://gitlab.com/gitlab-org/gitlab/-/work_items/606036).\n\nSecurity dashboards are now available at the organization level.\n\nUsers can see the following data across all top-level groups in an organization:\n\nIn GitLab 19.4, the GitLab MCP server provides the following new tools for vulnerability management:\n\n`list_vulnerabilities`, which lists security vulnerabilities in a GitLab project with optional filtering\nby severity and report type, with cursor pagination.`get_vulnerability`, which fetches full details for a single vulnerability by numeric ID, converting\nit to the `gid://gitlab/Vulnerability/<id>` global ID format.`save_vulnerability`, which covers five write operations on GitLab vulnerabilities in a single\nconsolidated tool:\nThese new vulnerability management tools allow AI agents to run vulnerability triage and remediation actions through the GitLab MCP server.\n\nGitLab 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.\n\nGitLab 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.\n\nGeo SSH proxying enabled by default\n\nThe following feature flags are enabled by default in GitLab 19.4:\n\n`geo_proxy_fetch_ssh_to_primary`` geo_proxy_push_ssh_to_primary`\nGeo SSH proxying provides a more reliable path for SSH fetches and pushes to a Geo secondary site when the operation\nis proxied to the primary site. It also resolves long-standing bugs where proxied operations failed, such as\n[pushes with push options](https://gitlab.com/gitlab-org/gitlab/-/issues/417186) and\n[fetches from large repositories](https://gitlab.com/gitlab-org/gitlab/-/issues/454707).\n\n**Action required for Cloud Native GitLab deployments**\n\nCloud Native GitLab deployments using the **bundled NGINX Ingress** must either:\n\nOtherwise, SSH fetches and pushes through Geo secondaries may hang or time out.\n\nSee the [Geo troubleshooting documentation](https://docs.gitlab.com/administration/geo/replication/troubleshooting/ssh_proxying/) for SSH proxying for more information.\n\nWhen 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.\n\nGitLab 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.\n\nThe 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.\n\nThe 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.\n\nCredit 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.\n\nThe new **Credit caps** page lets you set the flat cap that applies to every\nuser by default, and add per-user overrides for individual users through a\nsearchable picker.\nThis page is available in **GitLab Credits** for group Owners on GitLab.com and administrators on GitLab Self-Managed.\nThe GraphQL mutations still\nwork if you prefer to script cap changes.\n\nWhen an LDAP group sync fails, the reason now reaches you. The failure is recorded against the\ngroup, the members that caused it are named (up to five), and a danger alert appears on the group\nmembers page, so a sync blocked by an email-domain restriction is diagnosable from the UI. A new\n`group_filter` setting lets you narrow which LDAP entries count as groups. The audit log also\ndistinguishes causes that previously shared one entry: LDAP group links created and removed, and\nusers blocked by LDAP sync, each now get their own audit event type.\n\nThank you to [Sergey Pechenko](https://gitlab.com/tnt4brain) for these contributions\n([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))!\n\nWhile GitLab checks a merge request, the widget now tells you. **Merge conflicts must be resolved**\nbecomes **Checking for merge conflicts** until the check finishes. When a rebase is refused, you\nsee the specific reason, such as **Source branch is protected from force push**, instead of a\ngeneric retry prompt. You can act on the current state of the merge request.\n\nThe 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.\n\nThank you to the following users for these contributions!\n\nCommunity contributors added new tools for the GitLab MCP server. Agents can now use `get_project`\nand `list_project_members` to read project metadata and members, `list_branches` to list a\nrepository’s branches, and `list_merge_requests` to list merge requests across a whole group.\n`get_duo_session` fetches a GitLab Duo session so you can see what an earlier run did.\n\nThese 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.\n\nThe new file page now has **Write** and **Preview** tabs, the same pair the edit page has had for\nyears, so you can see how a Markdown or AsciiDoc file renders before its first commit exists.\nPreview keeps up with your edits: rename a file from `.txt` to `.md` mid-edit and the preview\nswitches renderer; rename it away from Markdown and the live preview stops. Snippets also gained\nMarkdown live preview, available from the editor’s right-click menu.\n\nThank you to [skkzsh](https://gitlab.com/skkzsh) for this contribution!\n\nOther improvements in this release include:\n\n`GET /projects/:id/jobs/:job_id/artifacts?file_type=junit` for a JUnit file.`Dependency-Scanning.v2` template.\nOther additions to the interface in this release include:\n\n`/internal_note` marks a comment internal as you create it, so internal notes can live inside\ncomment templates and saved replies.`/type Epic` promotes an issue to an epic, the same as `/promote_to Epic`.", "url": "https://wpnews.pro/news/gitlab-19-4-release-notes", "canonical_source": "https://docs.gitlab.com/releases/19/gitlab-19-4-released/", "published_at": "2026-09-17 00:00:00+00:00", "updated_at": "2026-10-01 21:51:03.059308+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-safety", "developer-tools", "ai-tools"], "entities": ["GitLab", "GitLab 19.4", "GitLab Duo Agent Platform", "GitLab Duo CLI", "Model Context Protocol", "GitLab Duo Slack integration", "Jimmy", "SPDX"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/gitlab-19-4-release-notes", "markdown": "https://wpnews.pro/news/gitlab-19-4-release-notes.md", "text": "https://wpnews.pro/news/gitlab-19-4-release-notes.txt", "jsonld": "https://wpnews.pro/news/gitlab-19-4-release-notes.jsonld"}}