GitLab 19.4（今後リリース予定）

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.

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.

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.

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.

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.