GitLab 19.5 release notes

The /goal slash command in GitLab Duo CLI is now generally available in GitLab Duo CLI 9.27.0.

Describe an open-ended goal, and GitLab Duo delegates it to a governed, goal-driven flow that runs locally and handles both implementation and verification.

To start, run /goal <task>. For example:

/goal Fix the failing tests in spec/models/user_spec.rb

In GitLab 19.5 (GitLab Duo CLI 9.24.0), the Run suggested prompts as /goal sessions setting in /settings runs suggested prompts as /goal sessions instead of chat messages.

/goal requires GitLab 19.3 and later, and GitLab Duo CLI 9.17.0 and later.

GitLab Duo CLI has a new auto mode. In auto mode, GitLab Duo uses tools without asking for approval first, so longer tasks run without stopping for each shell command, git operation, or MCP tool call.

Auto mode respects your organization’s controls:

• Auto mode is off by default. Administrators, Owners, and Maintainers can turn the setting on for instances, groups, and projects. Administrators and group Owners can also lock it to Always off for the entire instance or group.
• Agent tool governance still applies. Tools set to Always Deny stay blocked.

To use auto mode, you need GitLab Duo CLI 9.22.0 or later. Press Tab until the mode under the > prompt shows auto. Use auto mode only in repositories you trust and on branches you can discard.

You can now configure GitLab Duo CLI with settings files, for yourself or for your whole organization.

The settings file stores the choices you make in the /settings panel. You can also edit the file directly, or create it in advance, for example in a container image.

System administrators can deploy a managed settings file to each machine with a mobile device management tool or group policy. Settings in the managed file take precedence over the settings file, command-line options, and environment variables, and users can’t change them. Settings not in the managed file remain under user control.

The settings file requires GitLab Duo CLI 9.26.0 or later, and the managed settings file requires GitLab Duo CLI 9.27.0 or later.

In previous versions of GitLab, when you asked GitLab Duo to review a merge request again, it treated the review as a first pass. It could repeat findings from its earlier threads, even ones you had already addressed.

Now, Code Review Flow uses comment threads from earlier GitLab Duo reviews, including your replies, to evaluate new changes. GitLab Duo focuses on lines added after its last review, does not repeat points it already raised, and lists outstanding findings in its summary. If you reply on a thread to explain why the code is correct, GitLab Duo does not raise the point again.

To start a follow-up review, ask GitLab Duo to review the merge request again. With Start a new review on push turned on, GitLab Duo automatically starts a follow-up review when you push changes.

Previously, you could not control which AWS credentials the AI Gateway used for your Amazon Bedrock models. A single AWS identity needed access to all these models.

With this release, you can specify an IAM role for each model, and the AI Gateway assumes that role when calling the model. This way, each model gets only the AWS access it needs, even when the role is in another AWS account.

GitLab Duo CLI now helps new users get started without leaving the terminal:

• On first run, an onboarding card helps you connect MCP servers and install GitLab plugins.
• Each new session opens with prompts suggested from your open merge requests and issues. For a merge request prompt, GitLab Duo checks out the source branch first if it exists.
• The status bar shows your branch, project, merge request, /goal progress, and MCP status.
• The setup screen links to token creation and validates your token before saving.
• Tips in the prompt and the /whatsnew command point you to new features.

To get the full experience, update to GitLab Duo CLI 9.28.0 or later.

Previously, if you needed an agent to check something inside a CI/CD job’s build artifacts, it had to download and unzip the whole archive just to read one file. Now the get_artifact_file MCP tool lets your agent read a single file directly from a job’s artifacts, whether it’s a log, a generated report, or a test fixture.

New GitLab Duo agent and flow tools let you invoke and track GitLab Duo agents and flows from any MCP client:

• start_duo_session starts a session.
• get_duo_session reads a session’s current state.
• list_duo_sessions pages through your session history.
• list_duo_agents_and_flows lists the GitLab Duo agents and flows enabled in a project.

Previously, an agent connecting to GitLab over MCP had no way to discover which groups and subgroups you have access to without you hardcoding IDs or paths. The new list_groups tool lets your agent browse your organization’s group hierarchy on its own, so it can find the right group before acting instead of guessing at identifiers.

You can now choose which toolsets the GitLab MCP server exposes. Every additional tool that isn’t required wastes space in the LLM’s context window, and runs the risk of confusing the LLM, especially if you are using multiple MCP servers at once.

The redesigned GitLab Duo Agentic Chat UI in VS Code and JetBrains IDEs, introduced as a beta in GitLab 19.3, is now generally available and is the default layout. You no longer need to turn on beta and experimental features to use it.

The new layout has no tabs. You start conversations, view your chat history, and select an agent and model in the same view.

The new layout is the default in:

• GitLab for VS Code 7.2.0 and later
• GitLab Duo plugin for JetBrains IDEs 3.50.0 and later

To use the Software Development Flow or view the flows you have run, switch to the classic layout from the panel.

If you connect an agent to GitLab over MCP today, nothing stops it from reconnecting or retrying faster than your workflow actually needs, and on GitLab.com that carries a cost.

Starting October 15, the GitLab MCP server on GitLab.com limits each user to 60 requests a minute on the Free tier and 600 on Premium and Ultimate. Every reconnect and retry counts toward your limit. If your agent starts getting rate-limited (HTTP 429) errors, check its reconnect and retry settings before upgrading to a higher tier.

In previous versions of GitLab, the Developer Flow and Agentic Chat could only read text, so a screenshot on a bug report or a diagram in a design discussion never reached the model. Now the Developer Flow, including when you start it from Agentic Chat, and Agentic Chat in your IDE can read images in your repository and attachments on issues, merge requests, and comments in the same project, and use them as context.

You cannot upload an image directly in your prompt. Instead, name an image that already exists, by its file path in the repository or by its upload reference. For details, see the documentation.

In previous versions of GitLab, you had to check each approval rule and guess who had time to review your merge request. Or you assigned a whole group and hoped someone picked it up.

Now you can use the Recommend Reviewers Flow to suggest reviewers instead. The flow is generally available.

For each approval rule, it recommends the minimum number of reviewers needed, based on availability, workload, time zone, and recent activity.

Recommendations appear in the Recommended section of the merge request sidebar. Hover over a user to see why they were recommended.

To get started, turn on the flow for your top-level group. It runs when a merge request is created, or you can create a trigger to run it when a draft is marked ready. To get new recommendations, select Refresh.

The Software Development Flow now runs on the GitLab Duo Agent Platform flow registry, the same foundation as other flows. The flow works the same way in your IDE, and new fixes and improvements go to this version.

To keep using the Software Development Flow, update your editor extension to one of these versions or later:

• GitLab for VS Code 6.85.0
• GitLab Duo plugin for JetBrains IDEs 3.40.0
• GitLab for Visual Studio 0.79.0

In previous versions of GitLab, the API endpoint you use to trigger GitLab Duo Agent Platform flows from CI/CD pipelines, scripts, and other automation was an experiment, so it was hard to know whether you could rely on it in production. Now the trigger a flow endpoint of the Flows API is generally available, so you can build production automation on it knowing it follows the GitLab REST API breaking changes policy.

Many development teams split large CI/CD setups into parent and child pipelines so each part is easier to manage. Until now, a child pipeline job couldn’t safely depend on a parent job that only runs under certain conditions, such as tests that run only when certain files change. If that parent job was skipped, the child job broke, so teams had to work around it with duplicate jobs or brittle scripts.

Now you can mark these dependencies as optional. If the parent job runs, the child waits for it as usual. If it doesn’t run, the child job goes ahead without it. Pipelines stay fast and reliable without the workarounds, and a failure in a job that does run still stops the pipeline, so quality checks aren’t weakened.

Thank you to Jimmy Spagnola for this contribution!

You can now customize Secret Detection and SAST profiles in the UI. Set scan options like excluded paths, custom analyzer images, and full Git history scans once for a group, and apply them to all its projects.

Previously, a security configuration profile enabled a scanner with its default settings. Anything beyond the defaults required edits to .gitlab-ci.yml in each project. Now the profile includes those settings too.

Currently, customization of Dependency Scanning profiles is only available through the GraphQL API. UI customization is planned in a future release.

In previous versions of GitLab, permalinks to a file’s lines rendered as plain URLs, so you had to leave the merge request, issue, or wiki page to view the referenced code.

Now, permalinks render as a syntax-highlighted snippet with the file path and commit, so you can read the code without leaving the page. You can only view embedded snippets if you have read access to the repository.

In previous versions of GitLab, Observability was an experiment. Now it’s in beta on GitLab.com and GitLab Self-Managed.

With GitLab Observability, you can send traces, metrics, and logs with OpenTelemetry, then explore them next to your code, merge requests, and CI/CD pipelines. On GitLab.com, each group or personal namespace opts in by selecting Enable Observability. On GitLab Self-Managed, you host the Observability backend and connect it to a group or personal namespace. Observability is available at no cost during the beta.

In previous versions of GitLab, to find information in a large Markdown table, you had to scan every row or copy the table into a spreadsheet.

Now you can sort rendered Markdown tables by any column, in both view mode and preview. In a column header, select the sort button to sort rows in ascending or descending order, then reset to restore the original order. You can also sort with a keyboard.

In previous versions of GitLab, when you scrolled through a long table, the header row scrolled out of view, so it was hard to tell what each column contained.

Now, table headers stay visible at the top of the table as you scroll, in view mode, preview, and the rich text editor. Sticky headers are always on, so you don’t need to change any settings.

In previous versions of GitLab, if a scan had more than 25 findings of one severity, the security report compared only 25 of them from each pipeline. Unchanged findings could appear as new or fixed.

Now, the report compares up to 1,000 findings per severity, so the new and fixed lists are more accurate.

In previous versions of GitLab, you could run the SAST False Positive Detection, SAST Vulnerability Resolution, and Secret False Positive Detection flows only on vulnerabilities in the default branch.

Now, you can also run these flows on vulnerabilities in other tracked branches from the vulnerability report to analyze and resolve them before you merge.

Business Logic Security Analyzer is a GitLab Duo Agent Platform foundational flow that reasons about what your code is meant to enforce. It finds vulnerabilities that pattern-based scanners often miss: broken object-level authorization, missing authorization checks, and mass assignment.

Start a whole-repository scan from GitLab Duo Chat or the API. To scan merge requests automatically, attach the Business Logic scan profile to a project. Findings appear in the vulnerability report and the merge request security widget.

Business Logic Security Analyzer is in closed beta for GitLab Ultimate customers on GitLab.com. To request access, contact your account team. Each scan consumes GitLab Credits. For prerequisites and setup, see Business logic scanning.

GitLab Relay (KAS) now uses gRPC by default. GitLab.com advertised grpcs://kas.gitlab.com in GitLab 19.4. In GitLab 19.5, new Linux package and Helm chart installations advertise grpcs:// too. New agent installations connect over grpcs:// instead of gRPC wrapped in WebSocket, which means one protocol to route and troubleshoot, and less overhead for each connection.

Agents that already connect over wss:// work, but you should move them. On GitLab.com, set the agent address to grpcs://kas.gitlab.com. For example, use --set config.kasAddress=grpcs://kas.gitlab.com when you upgrade the gitlab-agent Helm chart. On GitLab Self-Managed, use the address shown in the agent installation command after you upgrade.

We’re also releasing GitLab Runner 19.5 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

• Clearer Kubernetes executor error message when the helper container is OOM-killed
• Log the CPU model of the job execution environment at job start

Bug Fixes

• IPv4-only services fail on dual-stack networks because Docker service health check dials only the last resolved address
• Runner and job tokens with an instance prefix are not recognized
• Kubernetes executor sends an unpaginated events LIST request on every poll, saturating API Priority and Fairness on busy clusters
• Docker executor applies mac_address to service containers instead of only the build container
• RUNNER_AFTER_SCRIPT_TIMEOUT is reset to 5 minutes when it exceeds the job timeout
• Cache upload fails with 403 on S3 servers that enforce SigV4 signed-header rules because cache_archiver sends a Content-Type the presigned URL does not sign
• Kubernetes executor always sets an empty pod-level resources object, causing BestEffort QoS misclassification on Kubernetes 1.34 and later
• Step-runner local server reports ready before its gRPC server is listening
• Documented systemd graceful shutdown configuration kills the running VM for the VirtualBox, Parallels, and SSH executors
• proxy_exec prints the helper binary help and exits instead of running the job when the image has a multi-argument ENTRYPOINT
• Docker executor ignores the platform parameter when multiple platforms of the same image are pulled

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

You can now share a filtered view of the security inventory with a link. Filter by tool coverage, vulnerability count, or project name, then copy the URL and send it. Whoever opens the link sees the same view.

Previously, only the project name search was saved in the URL, so a shared link lost the other filters. Now the full filter state is preserved, so you can bookmark a view or hand it to the team that owns those projects.

You can now start a custom flow directly from GitLab Duo Agentic Chat, without needing to configure a trigger first. Previously, running a custom flow required setting up a trigger event — a mention, an assignment, or similar — which made flows difficult to test and iterate on. Now, you can launch any AI Catalog flow enabled in your project by sending a message in GitLab Duo Agentic Chat. Your message becomes the goal for the flow. If you send no goal, the flow falls back to its own description. Chat links to the resulting agent session so you can follow along.

If you used GitLab Credits, you had no way to check your own usage. Only group Owners and administrators could open the GitLab Credits dashboard, so you had to ask someone with access.

You can now see your own usage in User settings > GitLab Credits. The page shows your total usage, daily average, and peak day, and you can filter by product or select a date range. If you belong to more than one group with GitLab Credits, you can switch between them.