{"slug": "gitlab-19-3-release-notes", "title": "GitLab 19.3 release notes", "summary": "GitLab 19.3, released on August 20, 2026, introduces the Flow Creator foundational agent in the AI Catalog for creating custom flows via plain-language conversation, GitLab Duo-powered merge conflict resolution and code review comment resolution, and GitLab Duo CLI plugins with marketplaces. The release also includes a redesigned Agentic Chat UI in the GitLab for VS Code extension 6.87.0 and a new get_merge_request API for retrieving merge requests with related data in a single call.", "body_md": "On August 20, 2026, GitLab 19.3 was released with the following features.\n\nWe are excited to recognize [gkepas](https://gitlab.com/gkepas)\nas this month’s [Notable Contributor](https://contributors.gitlab.com/notable-contributors)!\n\nGiannis has made sustained contributions across the GitLab codebase, the contributor\nplatform, `client-go`\n\n, the Terraform provider, and GitLab Orbit.\nHe is also an active translator and a member of the GitLab Community Discord.\n\nYou can now use the Flow Creator, a purpose-built foundational agent in the AI Catalog, to create custom flows for the GitLab Duo Agent Platform through a plain-language conversation. With the Flow Creator, you describe what you want the flow to do, and the agent produces a complete, runnable flow YAML you can register and use immediately. The agent can also help you debug existing flows and explain framework concepts.\n\nIn previous versions of GitLab, you had to resolve merge conflicts manually in the GitLab UI or from the command line, even for straightforward cases.\n\nNow you can ask GitLab Duo to resolve conflicts for you.\n\nStart conflict resolution from the merge widget or the **Resolve conflicts** page.\nGitLab Duo analyzes the conflicts, edits the files and commits the resolution to the source branch, and then posts a summary comment on the merge request describing what changed.\n\nIn previous versions of GitLab, to resolve a code review comment, you had to switch to your editor, implement the fix, commit and push the change, and then manually close the thread.\n\nNow you can select **Resolve with GitLab Duo** and GitLab Duo will address the review discussion for you.\n\nGitLab Duo reads the comment and the surrounding code, makes the requested change on the source branch, replies to the discussion with a summary of what changed, and then resolves the thread. If the change does not address the comment correctly, you or the reviewer can reopen the thread.\n\nGitLab Duo CLI now supports plugins and plugin marketplaces as an experiment, introduced in GitLab Duo CLI 9.10.0. A plugin bundles Agent Skills, custom slash commands, and Model Context Protocol (MCP) servers into a single directory. A marketplace is a catalog of available plugins, hosted in a Git repository or a local directory.\n\nGitLab Duo CLI automatically registers the official `gitlab-duo-plugins`\n\nmarketplace the first\ntime you use plugins.\n\nThe marketplace includes three skills for common GitLab workflows:\n\n`mr-review`\n\n: Reviews a merge request and posts comments.`stack-changes`\n\n: Splits a large local\nchange into a stacked merge request chain.`create-issue`\n\n: Drafts a GitLab issue from a\nnatural-language description.To install one of the skills, run `glab duo cli plugin install <plugin>@gitlab-duo-plugins`\n\nor `duo plugin install <plugin>@gitlab-duo-plugins`\n\n, based on your setup.\n\nFor compatibility with the existing community plugin ecosystem, GitLab Duo CLI also reads\n`.claude-plugin/marketplace.json`\n\nfiles, so existing Claude Code plugin marketplaces work with\nGitLab Duo CLI without modification.\n\nThe GitLab Duo Agentic Chat interface in the GitLab for VS Code extension has a redesigned UI, now available as a beta. The new interface is a rebuilt version of the existing Agentic Chat panel, with the same underlying capabilities: AI models, agents, slash commands, and tool approvals.\n\nThe redesigned UI is available in GitLab 19.3 with GitLab for VS Code extension 6.87.0 and later.\n\nTo use the new UI, [turn on beta and experimental features](/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features) for your top-level group or instance, then reload the extension.\n\nYou can switch between the new and classic UI at any time from the panel. The beta is available for VS Code only.\n\nYou can now use `get_merge_request`\n\nto retrieve a merge request along with its diffs, commits,\nnotes, pipelines, or discussions in a single call, so your AI agent no longer has to chain\nmultiple requests to get the full picture of an MR.\n\nYou can also use the new `list_merge_requests`\n\ntool to search and filter merge requests by author, assignee, reviewer, state, labels, or\nfree-text query, making it easy to find exactly the MRs you care about without leaving your workflow.\n\nPreviously, the `mcp`\n\nscope was hidden from the OAuth applications form in the **Admin** area, so you couldn’t\npre-register an OAuth application for your MCP clients without using Dynamic Client Registration (DCR).\nNow you can create a shared OAuth application with the `mcp`\n\nscope directly\nfrom the **Admin** area, giving your users a stable client ID to reuse and\nhelping you avoid DCR rate limits on shared networks.\n\nPreviously, when MCP clients connected to GitLab using OAuth Dynamic Client Registration (DCR),\nall dynamically-registered OAuth applications appeared in the Admin Area with only a generic\nclient name, making it impossible to tell which user authorized a given application.\nNow, when you approve an MCP OAuth connection, your username is automatically appended to the\napplication name — for example, `[Unverified Dynamic Application] kiro — authorized by @username`\n\n.\nYou can quickly identify which user is behind each dynamic OAuth application directly from the\nAdmin Area, without any additional configuration.\n\nPreviously, when you opened a session detail page, you had to manually expand individual activity log entries to find the agent’s current task list. Now, the session detail sidebar shows the agent’s latest plan automatically. You can view each task and its status, and a progress summary like “2 of 5 completed.” You can track what the agent is working on and how far along it is without digging through the activity log.\n\nMistral has deprecated the Devstral 2 model, and GitLab has deprecated Devstral 2 for GitLab Duo Agent Platform Self-Hosted. Mistral Medium 3.5 is a supported alternative available from Mistral.\n\nIf you use GitLab Self-Managed with self-hosted models, you can now use Amazon Bedrock Mantle as a supported provider. Mantle is an OpenAI-compatible inference engine for Amazon Bedrock, so you can use familiar OpenAI SDKs and integrations with Bedrock models. This feature is in beta.\n\nIn previous versions of GitLab, you couldn’t stop merges from bypassing the train. Both the option to merge immediately and the REST API could skip merge train protections without restriction. For teams running high-velocity monorepos, a single merge that skips the train can cancel and restart every in-progress pipeline, multiplying CI costs and straining infrastructure.\n\nNow you can enforce merge train usage across the UI and API with a single project-level setting, preventing bypasses that cancel and restart in-progress pipelines. Owners and Administrators can still override the setting when needed.\n\nGitLab Secret Scanning for Source Code is now in beta, powered by a new GitLab-built scan engine. Unlike the default analyzer, which detects only known secret patterns, this analyzer also detects passwords and other unstructured secrets that fall outside standard ruleset coverage. It also uses multiple heuristic techniques to reduce false positives. The new analyzer replaces the default analyzer in the same `secret_detection`\n\njob, matching existing vulnerability findings instead of creating duplicates.\n\nTo get started, see\n[turn on the analyzer](/user/application_security/secret_detection/gitlab_secret_scanner/#turn-on-the-analyzer).\nDuring beta, only high-confidence findings are reported.\n\nWe welcome any feedback you have in [issue 609578](https://gitlab.com/gitlab-org/gitlab/-/work_items/609578).\n\nSecret detection on the default branch now scans all commit diffs in a push when a prior commit reference is available, rather than scanning only the latest directory contents. This change closes a gap where secrets introduced and removed within the same push went undetected. The behavior now aligns with how secret detection works on merge requests and feature branches.\n\nThis scanning catches secrets that briefly existed in your repository history even if removed before the pipeline completes. Security teams can now identify secrets that were ever committed, not just those present at HEAD.\n\nFor more information, see [pipeline secret detection coverage](/user/application_security/secret_detection/pipeline/#coverage).\n\nPreviously, MCP clients and AI tools could automatically register OAuth applications on your instance through Dynamic Client Registration (DCR), which you couldn’t turn off. This made it difficult for administrators on GitLab Self-Managed and GitLab Dedicated instances to control which OAuth clients could connect.\n\nNow you can disable DCR entirely using the application settings API, giving you full control over which OAuth clients can access your instance. When DCR is disabled, clients must use a pre-registered OAuth application instead of registering automatically.\n\nGitLab 19.3 adds support for Software Package Data Exchange (SPDX) license expressions in CycloneDX Software Bill of Materials (SBOM) files you bring to GitLab. Previously, components with composite or custom licenses defined using SPDX expression syntax would appear as unknown.\n\nNow GitLab reads and stores the `expression`\n\nfield from CycloneDX\nlicense entries, including complex expressions like `MIT AND Apache-2.0`\n\nand custom license\nreferences using the `LicenseRef-[NAME]`\n\nsyntax.\n\nSPDX expression support is especially useful for organizations that generate their own SBOMs and have components with complex or custom license expressions, giving you an accurate view of your license exposure without requiring GitLab-generated scans.\n\nFor more information, see [Bring your own CycloneDX SBOM](/user/application_security/dependency_scanning/dependency_scanning_sbom/).\n\nIn earlier versions of GitLab, when secret push protection couldn’t complete a scan and allowed a push through unscanned, GitLab provided no customer-visible audit trail. Security and compliance teams had no way to monitor when secret push protection silently allowed a push to their repositories.\n\nGitLab 19.3 and later generates [audit events](/user/compliance/audit_event_types/#secret-detection) for all fail-open scenarios,\nincluding ruleset errors, exceeded file and line limits, scan timeouts, and unexpected errors. Teams can now forward these events to external\nmonitoring and alerting tools to maintain visibility into their security posture.\n\nIn previous versions of GitLab, projects using the Bun JavaScript runtime and package manager had no dependency scanning coverage.\n\nNow, GitLab dependency scanning analyzes Bun projects by parsing `bun.lock`\n\nfiles\n(the text-based JSONC format introduced in Bun 1.2).\n\nBecause Bun packages are sourced from the npm registry, the GitLab advisory database already covers these dependencies with no additional configuration required. Teams using Bun as an alternative to npm, yarn, or pnpm can now scan their projects for known vulnerabilities as part of their standard CI/CD pipelines. Eligible findings are also supported by dependency scanning auto-remediation.\n\nIn the Vulnerability Report, you can now select multiple vulnerabilities and run SAST Vulnerability Resolution and SAST False Positive Analysis flows on all of them at once.\n\nWe’re also releasing GitLab Runner 19.3 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\n`clear-docker-cache`\n\nprunes all unused images when `IMAGE_FILTER_FLAGS`\n\nis empty`When`\n\nis unset`PrintPodWarningEvents`\n\ndoesn’t work`.git`\n\nfolder is corruptThe list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/19-3-stable/CHANGELOG.md).\n\nGitLab now fully supports Kubernetes version 1.36. To deploy your applications to Kubernetes\nand access all features, upgrade your connected clusters to the most recent version.\nFor more information, see [supported Kubernetes versions for GitLab features](/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features).\n\nThe vulnerability details page has been refreshed with an updated design that makes reviewing and triaging vulnerabilities easier and more efficient.\n\nThe Security Dashboard now includes a SAST triage and remediation funnel. This funnel shows how critical and high SAST vulnerabilities move through triage and remediation over a 30-, 60-, or 90-day window. The funnel traces each stage: detected vulnerabilities, true positives confirmed by SAST false positive detection, vulnerabilities with merge requests created by Agentic SAST Vulnerability Resolution, and vulnerabilities fixed by merged merge requests. These stages show how much of your workflow AI powers and which stages you can scale further.\n\nYou can now opt-in to using PostgreSQL 18.4 when performing a fresh install using the Linux packages.\n\nUpgrades to PostgreSQL 18.4 for existing installations is not yet supported.\n\nFor more information, refer to the relevant [documentation](https://docs.gitlab.com/omnibus/settings/database/#pin-the-packaged-postgresql-version-fresh-installs-only).\n\nYou can now set custom agents and custom flows to **Restricted visibility** for every group, subgroup, and project in your top-level group.\n\nPreviously, you could only set a custom flow or agent to **Private** (one project only) or **Public** (visible to everyone on GitLab.com). When you set the visibility to **Restricted**, the flow or agent is visible to only groups, subgroup, and projects in your top-level group. This ensures that internal logic about your custom agents and flows are not shared outside your company or organization.\n\nGitLab Advanced SAST now supports Objective-C and Swift, bringing the same interprocedural taint analysis it delivers for other languages to iOS development. The beta is available for all GitLab Ultimate customers starting in GitLab 19.3.\n\nThe beta detects key OWASP Mobile Top 10 vulnerability classes, including insecure data storage, broken cryptography, insecure communication, and authentication and authorization flaws. When a vulnerability begins in one language and reaches a sink in the other, Advanced SAST detects the complete taint path, including paths that cross the Swift and Objective-C language boundary.\n\nTo enable, set `GITLAB_ADVANCED_SAST_ENABLED: 'true'`\n\nin your pipeline. If your project\ncontains Objective-C or Swift files, the `gitlab-advanced-sast-ext`\n\njob runs automatically.\nFor full setup instructions, see the\n[Advanced SAST documentation](/user/application_security/sast/gitlab_advanced_sast/).\n\nShare feedback in the [beta feedback issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/607091).\n\nIn previous versions of GitLab, you had no warning when your Flex usage approached a limit. GitLab now sends billing account managers an email notification when a product reaches 50%, 80%, or 100% of its monthly reservation, and when a capped product reaches its spend cap and is cut off for the rest of the billing period. Each threshold triggers at most one email per product per billing period, so you can act on overage early without getting repeat emails for the same threshold.\n\nOn-demand usage can run up overage charges you didn’t plan for. Usage caps for GitLab Credits are now generally available: set a subscription-level cap on on-demand credits in Customers Portal, and set a default per-user cap or per-user overrides with the GraphQL API. When consumption reaches a cap, features that consume GitLab Credits, like GitLab Duo Agent Platform, are suspended until the next billing period begins or an administrator adjusts the cap. Usage caps were introduced in GitLab 18.11 behind the `budget_caps_graphql_api`\n\nfeature flag. In GitLab 19.3, the feature flag is removed.\n\nWith GitLab Flex, overage from one capability draws down the same commitment every other capability depends on. You can now set a spend cap for each capability when you adjust your Flex reservation in the Customers Portal: **Restricted** (no overage past the reservation), **Usage cap** (a bounded amount of overage), or **Unlimited** (unlimited overage past the reservation). When a capped capability reaches its cap, its usage stops for the rest of the billing period, and capabilities without a cap keep running.", "url": "https://wpnews.pro/news/gitlab-19-3-release-notes", "canonical_source": "https://docs.gitlab.com/releases/19/gitlab-19-3-released/", "published_at": "2026-08-20 00:00:00+00:00", "updated_at": "2026-08-20 20:43:44.470435+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-agents", "developer-tools"], "entities": ["GitLab", "GitLab Duo", "GitLab Duo CLI", "GitLab for VS Code", "Flow Creator", "gkepas", "GitLab Orbit"], "alternates": {"html": "https://wpnews.pro/news/gitlab-19-3-release-notes", "markdown": "https://wpnews.pro/news/gitlab-19-3-release-notes.md", "text": "https://wpnews.pro/news/gitlab-19-3-release-notes.txt", "jsonld": "https://wpnews.pro/news/gitlab-19-3-release-notes.jsonld"}}