GitLab 19.4 release notes

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.

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.
• list_merge_requests now works at group scope.
• 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:

• get_project and list_projects find and read project details.
• list_project_members enumerates members and their roles.
• get_user looks up user details for assignment and mentions.

Previously, agents had no way to discover project membership 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_branches and list_tags enumerate 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.

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:

• Conservative: on demand, high severity.
• Standard: automatic, medium severity and above.
• Proactive: automatic, every severity.

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.

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

• Fastzip is now the default archiver for caches and artifacts
• Add runner and system_id labels to gitlab_runner_job_router_get_job_duration_seconds
• Add a dedicated SLI, SLO, and alerting integration for the Job Router
• Add suspend and resume support for the Kubernetes executor
• Emit the environment key on job-complete PUT request
• Option to suppress the cache upload and download URL in job logs
• Add services_cap_add and services_cap_drop options to the Docker executor configuration

Bug Fixes

• Job router 409 responses disable runner managers for an hour
• The logrotate usage writer can panic the runner by mutating shared runner labels
• Windows service console restore failure force-kills a job that is stopping gracefully
• Unbounded cardinality for the job_id and runner_controller_id attributes in a histogram
• Config validation warns got null for nil-able fields that have a TOML tag but no JSON tag
• Intermittent silent failure in get_sources caused by SIGPIPE in the Git version check
• Spurious Request bottleneck warning when FF_USE_ADAPTIVE_REQUEST_CONCURRENCY is enabled
• Secret-resolution failures for AWS, GCP, Azure, and GitLab Secrets Manager are now classified by cause
• Kubernetes pause pods fail to start when the runner short ID begins with -
• Canceling a job always results in a process kill when running as a Windows service

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

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.

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:
  • dismiss. Mark a vulnerability as dismissed, with optional comment and dismissal reason.
  • confirm. Mark a vulnerability as confirmed.
  • revert_to_detected. Revert a vulnerability’s state back to detected.
  • update_severity. Override the severity with a required comment.
  • link_to_issue. Create a new issue linked to the vulnerability (requires project_full_path).

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:

• upgrade to use the Gateway API with Envoy Gateway before this rollout, or
• disable both feature flags after the rollout.

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.