{"slug": "gitlab-19-5-release-notes", "title": "GitLab 19.5 release notes", "summary": "GitLab released version 19.5 on October 15, 2026, making the GitLab MCP server and GitLab Secrets Manager generally available. The MCP server gives MCP-compatible agents such as Claude Code and Cursor direct access to GitLab's expanded tool catalog and GitLab Duo Agent Platform agents and flows, while Secrets Manager, built on OpenBao, scopes each CI secret to the job that needs it and generates audit logs for every create, read, update, and delete. The release also extends the AI Governance Dashboard to Externally Connected Agents like Claude Code, Cursor, and Codex via a one-time `glab govern setup`, in beta, and makes non-default branch vulnerability tracking generally available.", "body_md": "On October 15, 2026, GitLab 19.5 was released with the following features.\n\nWe are excited to recognize [Dhairya](https://gitlab.com/DhairyaMajmudar), a Level 3 contributor,\nas this month’s [Notable Contributor](https://contributors.gitlab.com/notable-contributors)!\n\nDhairya contributed to offline transfer and Organizations support for import, so that groups, projects, and their memberships can move between GitLab instances.\n\nIn previous versions of GitLab, MCP clients could reach only a limited set of GitLab tools. Now the GitLab MCP server is generally available.\n\nWith the MCP server, any MCP-compatible agent, such as Claude Code or Cursor, gets direct access to the expanded GitLab catalog of tools and GitLab Duo Agent Platform agents and flows. Your agents can work across more of your GitLab workflow and run Agent Platform agents and flows without leaving your preferred tool.\n\nWithout a centralized secrets store, credentials can become scattered across over-scoped CI/CD variables, local config files, and standalone vaults. This makes them harder to manage, protect, and audit.\n\nGitLab Secrets Manager is now generally available on GitLab.com and GitLab Self-Managed. Built on OpenBao, it uses your existing group and project permissions, so there’s no separate access model to maintain. Each CI secret is scoped to the job that needs it, based on environment, branch, and branch protection rules. Audit logs are generated for every create, read, update, and delete.\n\nGitLab Secrets Manager consumes GitLab Credits. [Start a free 30-day trial](https://docs.gitlab.com/ci/secrets/secrets_manager/credit_usage/#start-a-trial) or [enable it for your group or instance](https://docs.gitlab.com/ci/secrets/secrets_manager/#enable-gitlab-secrets-manager).\n\nPreviously, the [AI Governance Dashboard](https://docs.gitlab.com/user/ai-governance/governance-dashboard/) showed\nactivity only from GitLab Duo Agent Platform agents. This provided you total visibility into all of your\nAgent Platform agents, including the sessions they were running, including tool calls, MCPs used, and\nthe prompt input and output from the user and agent respectively.\n\nWith the GitLab 19.5 release, after a one-time `glab govern setup`, you can now extend governance\nvisibility past just GitLab Duo Agent Platform agents, and connect Externally Connected Agents (ECAs) like\nClaude Code, Cursor, and Codex to GitLab AI Governance by using the GitLab CLI (`glab`).\n\nWhen **Allow external agents** and **Store AI audit events** are enabled, security and compliance teams\nget visibility into ECAs that run outside GitLab, alongside your GitLab Duo Agent Platform agents. Every qualifying\nagent session is captured, including who ran it, which agent, which project, and when, with sessions and\ntool calls appearing in the AI Governance Dashboard and the AI audit events report. Audit events also\nflow to your SIEM through audit event streaming.\n\nTool output is not sent, except for short error messages from failed tool calls.\n\nThis feature is in beta. Share your feedback in [issue 633489](https://gitlab.com/gitlab-org/gitlab/-/work_items/633489).\n\nNon-default branch tracking is now generally available. You can track vulnerabilities on branches\nother than the default branch. For the best results, target a small number of long-lived release\nbranches, such as branches for specific environments (`project-qa`, `project-prod`) or deployment\nplatforms (`project-iOS`, `project-android`).\n\nThis release includes the following capabilities:\n\nAdministrators can now select any subgroup, not just top-level groups, in the [**Restrict access based on group membership**](https://docs.gitlab.com/administration/gitlab_duo/configure/access_control/) setting for GitLab Duo. You can scope GitLab Duo Agent Platform access to a specific team or pilot group without restructuring your group hierarchy.\n\nPreviously, this setting accepted only top-level groups. Organizations with a single top-level group for all users had no supported way to limit GitLab Duo Agent Platform access to a subset of users.\n\nNow, when you select a subgroup, direct members of that subgroup get access. This makes it easier to run a GitLab Duo Agent Platform pilot or roll out access one division at a time on GitLab Self-Managed and GitLab Dedicated.\n\nThe `/goal` slash command in GitLab Duo CLI is now generally available in GitLab Duo CLI 9.27.0.\n\nDescribe an open-ended goal, and GitLab Duo delegates it to a governed, goal-driven flow that runs locally and handles both implementation and verification.\n\nTo start, run `/goal <task>`. For example:\n\n```\n/goal Fix the failing tests in spec/models/user_spec.rb\n```\n\nIn GitLab 19.5 (GitLab Duo CLI 9.24.0), the **Run suggested prompts as /goal sessions** setting\nin `/settings` runs suggested prompts as `/goal` sessions instead of chat messages.\n\n`/goal` requires GitLab 19.3 and later, and GitLab Duo CLI 9.17.0 and later.\n\nGitLab Duo CLI has a new auto mode.\nIn auto mode, GitLab Duo uses tools without asking for approval first, so longer tasks run\nwithout stopping for each shell command, `git` operation, or MCP tool call.\n\nAuto mode respects your organization’s controls:\n\nTo use auto mode, you need GitLab Duo CLI 9.22.0 or later.\nPress `Tab` until the mode under the `>` prompt shows `auto`.\nUse auto mode only in repositories you trust and on branches you can discard.\n\nYou can now configure GitLab Duo CLI with settings files, for yourself or for your whole organization.\n\nThe settings file stores the choices you make in the `/settings` panel.\nYou can also edit the file directly, or create it in advance, for example in a container image.\n\nSystem 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.\n\nThe 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.\n\nIn 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.\n\nNow, 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.\n\nTo start a follow-up review, ask GitLab Duo to review the merge request again. With\n**Start a new review on push** turned on, GitLab Duo automatically starts a follow-up review when you push changes.\n\nPreviously, 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.\n\nWith 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.\n\nPreviously, GitLab Duo CLI could read text files but could not use screenshots or diagrams as context. Now, when you run the CLI locally in interactive or headless mode, it can read images from your repository and attachments on issues, merge requests, and comments in the same project.\n\nImage context requires GitLab Duo CLI 9.27.0 or later and a GitLab-managed model.\n\nGitLab Duo CLI now helps new users get started without leaving the terminal:\n\n`/goal` progress, and MCP status.`/whatsnew` command point you to new features.\nTo get the full experience, update to GitLab Duo CLI 9.28.0 or later.\n\nPreviously, if you needed an agent to check something inside a CI/CD job’s build artifacts, it had to\ndownload and unzip the whole archive just to read one file. Now the `get_artifact_file` MCP\ntool lets your agent read a single file directly from a job’s artifacts, whether it’s a log, a\ngenerated report, or a test fixture.\n\nNew GitLab Duo agent and flow tools let you invoke and track GitLab Duo agents and flows from any MCP client:\n\n`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.\nPreviously, an agent connecting to GitLab over MCP had no way to discover which groups and\nsubgroups you have access to without you hardcoding IDs or paths. The new `list_groups` tool\nlets your agent browse your organization’s group hierarchy on its own, so it can find the right\ngroup before acting instead of guessing at identifiers.\n\nYou 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.\n\nThe 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.\n\nThe new layout has no tabs. You start conversations, view your chat history, and select an agent and model in the same view.\n\nThe new layout is the default in:\n\nTo use the Software Development Flow or view the flows you have run, switch to the classic layout from the panel.\n\nIf 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.\n\nStarting 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.\n\nIn 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.\n\nNow you can use the Recommend Reviewers Flow to suggest reviewers instead. The flow is generally available.\n\nFor each approval rule, it recommends the minimum number of reviewers needed, based on availability, workload, time zone, and recent activity.\n\nRecommendations appear in the **Recommended** section of the merge request sidebar. Hover over a user to see why they were recommended.\n\nTo get started, turn on the flow for your top-level group. It runs when a merge request is created,\nor you can create a trigger to run it when a draft is marked ready. To get new recommendations, select **Refresh**.\n\nThe 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.\n\nTo keep using the Software Development Flow, update your editor extension to one of these versions or later:\n\nIn previous versions of GitLab, the API endpoint you use to trigger GitLab Duo Agent Platform flows\nfrom CI/CD pipelines, scripts, and other automation was an experiment, so it was hard to know whether you could rely on it in production.\nNow the [trigger a flow endpoint](https://docs.gitlab.com/api/duo_agent_platform_flows/#trigger-a-flow) 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.\n\nMany 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.\n\nNow 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.\n\nThank you to [Jimmy Spagnola](https://gitlab.com/jspagnola) for this contribution!\n\nYou 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.\n\nPreviously, 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.\n\nCurrently, customization of Dependency Scanning profiles is only available through the GraphQL API. UI customization is planned in a future release.\n\nIn previous versions of GitLab,\n[permalinks](https://docs.gitlab.com/user/project/repository/files/#create-permalinks)\nto a file’s lines rendered as plain URLs, so you had to leave the merge request,\nissue, or wiki page to view the referenced code.\n\nNow, 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.\n\nIn previous versions of GitLab, Observability was an experiment. Now it’s in beta on GitLab.com and GitLab Self-Managed.\n\nWith GitLab Observability, you can send traces, metrics, and logs with OpenTelemetry, then explore them next to your code, merge requests, and CI/CD pipelines.\nOn GitLab.com, each group or personal namespace opts in by selecting **Enable Observability**.\nOn GitLab Self-Managed, you host the Observability backend and connect it to a group or personal namespace.\nObservability is available at no cost during the beta.\n\nIn 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.\n\nNow 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.\n\nIn 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.\n\nNow, 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.\n\nBusiness 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.\n\nStart 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.\n\nBusiness 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](https://docs.gitlab.com/user/application_security/business_logic_scanning/).\n\nGitLab Relay (KAS) now uses gRPC by default. GitLab.com advertised `grpcs://kas.gitlab.com` in\nGitLab 19.4. In GitLab 19.5, new Linux package and Helm chart installations advertise\n`grpcs://` too. New agent installations connect over `grpcs://` instead of gRPC wrapped in WebSocket,\nwhich means one protocol to route and troubleshoot, and less overhead for each connection.\n\nAgents that already connect over `wss://` work, but you should move them.\nOn GitLab.com, set the agent address to `grpcs://kas.gitlab.com`. For example, use\n`--set config.kasAddress=grpcs://kas.gitlab.com` when you upgrade the `gitlab-agent`\nHelm chart. On GitLab Self-Managed, use the address shown in the\n[agent installation command](https://docs.gitlab.com/user/clusters/agent/install/)\nafter you upgrade.\n\nYou 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.\n\nPreviously, 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.\n\nYou 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.\n\nIf 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.\n\nYou can now see your own usage in **User settings > GitLab Credits**. The page\nshows your total usage, daily average, and peak day, and you can filter by\nproduct or select a date range. If you belong to more than one group with\nGitLab Credits, you can switch between them.\n\nAdministrators can now resync a single LDAP-blocked user from the Admin area **Users** page.\nThe new **Resync with LDAP** action runs an LDAP access check and unblocks the user when LDAP\nallows access, or leaves the user blocked when it does not. If the user has no LDAP identity,\nthe action declines with a message. In previous versions of GitLab, an LDAP-blocked account\nstayed blocked until the daily user sync ran or the user signed in, which service accounts\ncannot do.\n\nThank you to [Sergey Pechenko](https://gitlab.com/tnt4brain) for this contribution ([MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255974))!\n\nYou can now cancel an active auto-merge with the `cancel_auto_merge` API endpoint.\nIf the merge request is on a merge train, the call also removes it from the train.\nThe older `cancel_merge_when_pipeline_succeeds` endpoint is now deprecated.\n\nSeparately, `git push -o merge_request.auto_merge` is now rejected with a remote message when\nyou cannot merge to the target branch. In previous versions of GitLab, the auto-merge was recorded\nand left the merge request unmergeable until canceled.\n\nThank you to the following users for these contributions!\n\nAdministrators can now set how often job logs update, under **Admin area** > **Settings** > **CI/CD**\nor through the Settings API. You can select between 3 to 3600 seconds.\nIn previous versions of GitLab, these intervals were constants, so you could not shorten\nthe initial live-log delay for short jobs without patching the instance.\n\nThank you to [Aleksandr Kotlyar](https://gitlab.com/aleksandr-kotlyar) for this contribution ([MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251401))!\n\nGraphQL now exposes `Repository.tags`, with forward pagination, search, and a `TagSort` enum\nfor name, updated, and version order, at up to 100 tags per page. `Repository.tags` is an\nexperiment in GitLab 19.5. `TerraformState.versions` lists a state’s versions, newest first.\nThe merge requests REST API now returns `author.bot` on single and list responses, so a client\ncan tell bot and service account authors apart without a second call to the Users API.\n\nYou can now use `%{commits_count}` in merge commit and squash commit message templates, and in\nnew merge request description templates. For example, `%{title} (%{commits_count} commits)`\nrenders as `Bugfix (3 commits)`.\n\nThank you to [Jeston Singh](https://gitlab.com/sjestonsingh) for this contribution ([MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255231))!\n\nWhen you submit a review on a merge request you are not yet a reviewer of, with **Comment**,\n**Approve**, or **Request changes**, GitLab now adds you to the **Reviewers** list. The review\ndrawer tells you beforehand: “You will be added as a reviewer.” The Reviewers list and the\npeople who took part in the review no longer drift apart. This behavior has been available\nsince GitLab 19.4, when its feature flag was removed.\n\nThank you to [Michael Fischer](https://gitlab.com/mfischer5) for this contribution ([MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/250880))!\n\nGitLab now ignores user IDs that GPG reports as revoked. A revoked identity no longer appears\nunder **Access** > **GPG keys** in user settings and no longer counts as a verified email for the\n**Verified** badge on signed commits. Commits signed under a revoked identity move to “same\nuser, different email” or “other user”, and a key whose every identity is revoked verifies\nnothing. Signatures already verified under a key that stays in place are not re-derived.\n\nThank you to [José M. Requena Plens](https://gitlab.com/jmrp) for this contribution ([MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255300))!\n\nOther improvements in this release include:\n\n`add_branch`\nreturns the branch `web_url`, tool aliases in the enabled-tools header resolve, mismatched\nURL and project ID inputs are rejected, and `ai_workflows` tokens can read blobs in batch.`CI_JOB_TAGS` and `CI_RUNNER_TAGS` JSON-encode each tag. Duplicate variable keys in push\noptions are rejected.`?scopes=` links prefill the\ntoken form.\nOther additions to the interface in this release include:\n\n`.4dm` files are syntax highlighted.\nApproval rules, compliance frameworks, and protected environments require Premium or Ultimate.", "url": "https://wpnews.pro/news/gitlab-19-5-release-notes", "canonical_source": "https://docs.gitlab.com/releases/19/gitlab-19-5-released/", "published_at": "2026-10-15 00:00:00+00:00", "updated_at": "2026-10-15 17:54:20.674430+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "developer-tools", "ai-policy", "mlops"], "entities": ["GitLab", "GitLab 19.5", "GitLab MCP server", "GitLab Secrets Manager", "OpenBao", "GitLab Duo Agent Platform", "Claude Code", "Cursor"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/gitlab-19-5-release-notes", "markdown": "https://wpnews.pro/news/gitlab-19-5-release-notes.md", "text": "https://wpnews.pro/news/gitlab-19-5-release-notes.txt", "jsonld": "https://wpnews.pro/news/gitlab-19-5-release-notes.jsonld"}}