What’s new in Eficode ROOT: June 2026

Slack slash commands integration removed

The Slack slash commands integration is deprecated in favor of the GitLab for Slack app, which provides a more secure integration with the same capabilities.

From GitLab 19.0, users will no longer be able to configure or use Slack slash commands. This integration only exists on GitLab Self-Managed and GitLab Dedicated — GitLab.com users are not affected. Learn more here.

Trending tab removed from Explore projects page

The Trending tab in Explore > Projects and its associated GraphQL arguments are removed in GitLab 19.0. The trending algorithm only considers public projects, making it ineffective for Self-Managed instances that primarily use internal or private project visibility.

In the month before the GitLab 19.0 release, the Trending tab on GitLab.com will redirect to the Active tab sorted by stars in descending order.

Also removed: the trending argument in the Query.adminProjects, Query.projects, and Organization.projects GraphQL types. Learn more here.

ciJobTokenScopeAddProject GraphQL mutation removed

The ciJobTokenScopeAddProject GraphQL mutation is deprecated in favor of ciJobTokenScopeAddGroupOrProject, introduced alongside the CI/CD job token scope changes in GitLab 18.0. Update any automation or tooling using the deprecated mutation before upgrading. Learn more here.

ci_job_token_scope_enabled projects API attribute removed

The ci_job_token_scope_enabled attribute in the Projects REST API is removed in GitLab 19.0. This attribute was deprecated in GitLab 18.0 when the underlying setting was removed, and has since always returned false.

To control CI/CD job token access, use the CI/CD job token project settings. Learn more here.

Resource Owner Password Credentials (ROPC) OAuth grant removed

Support for the Resource Owner Password Credentials (ROPC) grant as an OAuth flow will be fully removed in GitLab 19.0. This aligns with the OAuth RFC Version 2.1 standard, which removes ROPC due to its inherent security limitations.

GitLab has already required client authentication for ROPC on GitLab.com since April 8, 2025. An administrator setting was added in 18.0 to allow controlled opt-out ahead of the removal.

After the 19.0 upgrade, ROPC cannot be used under any circumstances, even with client credentials. Any applications or integrations using this grant type must migrate to a supported OAuth flow — such as the Authorization Code flow — before upgrading. Learn more here.

Mattermost removed from the Linux package

In GitLab 19.0, bundled Mattermost is removed from the Linux package. Mattermost was first bundled with GitLab in 2015, but has since matured its own standalone deployment options. Additionally, with Mattermost v11, GitLab SSO was deprecated from their free offering, reducing the value of the bundled integration.

Customers not using the bundled Mattermost will not be impacted. If you currently use it, refer to Migrating from GitLab Omnibus to Mattermost Standalone in the Mattermost documentation for migration instructions. Learn more here.

Per-session tool approvals with admin controls (all users)

Streamline your workflows by approving trusted tools once for an entire session. Administrators manage the availability of session-based tool approvals through settings that cascade from instance to group and down to the project level:

• On by default
• Off by default
• Always off

Unless an administrator enforces the Always off setting, groups and subgroups retain the ability to modify these preferences.

To ensure each tool invocation is intentional, the default configuration is set to Off by default, requiring explicit approval for every use unless adjusted by an administrator. Learn more here.

Restrict the AI Catalog to a group hierarchy (Premium, Ultimate)

To enhance organizational oversight, top-level group Owners now have the power to confine the AI Catalog exclusively to agents and flows originating from projects within their specific group hierarchy. By implementing this restriction, any agents, external agents, or flows existing outside of this hierarchy are effectively hidden and cannot be enabled by users in that group. Learn more here.

Secure webhooks with HMAC signing tokens (all users)

Traditional webhook security often relies on the X-Gitlab-Token header, which transmits a static secret in plain text and leaves your integrations vulnerable to interception or replay attacks.

To address this, you can now implement signing tokens for any webhook. In accordance with the Standard Webhooks specification, GitLab uses this token to generate an HMAC-SHA256 signature by combining:

• The unique ID of the webhook.
• The specific request timestamp.
• The entire webhook payload.

This signature is delivered via the webhook-signature header, accompanied by webhook-id and webhook-timestamp headers. By recomputing this signature on your end, you can verify that the request is legitimately from GitLab and ensure the payload remains unaltered. Furthermore, validating the provided timestamp allows you to effectively identify and discard replayed requests. Learn more here.

Group-level custom review instructions for GitLab Duo (Premium, Ultimate)

The introduction of shared custom review instructions now allows for centralized configuration at the group and subgroup levels.

By designating a specific project as a template, GitLab Duo can now automatically merge instructions from the group-level .gitlab/duo/mr-review-instructions.yaml file with any project-specific guidelines during a code review. This enhancement for group-level custom instructions is fully supported by both GitLab Duo Code Review and Code Review Flow. Learn more here.

GitLab Duo Developer enhancements for merge request workflows (all users)

Effortlessly transform feedback, tasks, and design queries into actionable code changes or research summaries using GitLab Duo Developer. This assistant now adapts to your workflow with multiple trigger options: simply assign it to an issue, select "Generate MR," or @mention it within any issue or merge request discussion.

To ensure quality and reliability, GitLab Duo Developer automatically executes your predefined tests and checks via AGENTS.md and agent-config.yml before any commits are finalized. Once the Developer Flow is enabled by an administrator at the instance or top-level group level, these convenient mention and assign triggers become automatically available across all eligible projects. Learn more here.

Merge request ready event trigger (Premium, Ultimate)

The Merge request ready event now supports the configuration of flows and external agents. GitLab Duo initiates the flow or external agent automatically as soon as a draft merge request is updated to a ready-for-review status. To set up a trigger, navigate to the AI > Triggers section within your project. Please note that this functionality is currently controlled by the merge_request_ready_flow_trigger feature flag and is turned off by default. Learn more here.

Claude Opus 4.7 now available in GitLab Duo Agent Platform (Premium, Ultimate)

The GitLab Duo Agent Platform now features Claude Opus 4.7. This version significantly enhances the handling of intricate, multi-stage operations that demand deep reasoning, strict adherence to instructions, and rigorous self-validation prior to output. These advancements benefit workflows such as CI/CD pipeline management, code reviews, and the remediation of vulnerabilities. Learn more here.

Support for self-hosted Gemini models (Premium, Ultimate)

The GitLab Duo Agent Platform Self-Hosted has expanded its capabilities with native support for Gemini models. This integration empowers your teams to leverage Gemini across various automated workflows, including the Code Review Flow, Fix CI/CD Pipeline Flow, and SAST Vulnerability Resolution Flow. Learn more here.

Expanded open source model support in GitLab Duo Agent Platform (Premium, Ultimate)

Self-hosted deployments now benefit from broader open-source model compatibility within the GitLab Duo Agent Platform, featuring integrations like GLM-5.1-FP8 and Devstral 2 123B. These additions empower customers to execute sophisticated agentic workflows even in network-restricted or offline environments. Learn more here.

Resolve merge conflicts with GitLab Duo (Beta) (Premium, Ultimate)

GitLab Duo now features autonomous merge conflict resolution, allowing it to analyze conflicts, modify files, and handle commits and pushes directly to the source branch. You can initiate this process through the merge request widget or via the Resolve conflicts page. To ensure full transparency for reviewers, the assistant provides a summary comment detailing all changes made during the resolution process. To maintain project integrity, GitLab Duo strictly adheres to branch protection rules and avoids force-pushing to any protected branches. Currently in beta, this functionality is managed by the mr_ai_resolve_conflicts feature flag, which is active by default. Learn more here.

Rapid Diffs for merge request reviews (Beta) (all users)

Large merge request reviews in GitLab used to be hindered by long wait times, as the Changes tab required all files to load before any reviewing could take place. With the introduction of Rapid Diffs—powered by the same efficient technology behind the commits page—you can now experience significantly faster initial loading, smoother scrolling, and a more fluid interface.

Please note that Rapid Diffs is currently in beta, meaning while it offers a more responsive experience, some classic diff features are still being integrated. You have the flexibility to toggle back to the traditional view at any time. Learn more here.

Customize default merge request titles (all users)

Projects now offer the ability to establish a customized default template for merge request titles. These templates utilize variables such as the source and target branches, the subject of the initial commit, linked issue IDs and titles, and a formatted version of the source branch name. For instance, using the template Resolve %{issue_id} "%{issue_title}" would automatically generate a title like Resolve 123 "Fix login bug". Even with a template in place, you retain the flexibility to manually adjust the title before finalizing the merge request. Learn more here.

Mermaid diagram rendering upgraded to version 11 (all users)

The transition from Mermaid 10 to version 11 in GitLab brings a wealth of new diagram types and syntax refinements. This update delivers enhanced rendering capabilities for sequence diagrams and flowcharts, alongside various bug fixes that improve the overall diagramming experience. Learn more here.

GitLab Duo Core moves to usage-based billing (Premium, Ultimate)

With the arrival of GitLab 19.0, GitLab Duo Core has shifted to a usage-based billing model, meaning Code Suggestions within the desktop and Web IDEs now utilize GitLab Credits.

Concurrently, GitLab Duo Chat has evolved into an agentic experience powered by the GitLab Duo Agent Platform for Duo Core users. To access Chat functionality in desktop IDEs or the GitLab UI, the GitLab Duo Agent Platform must be enabled at the top-level group or instance level. Learn more here.

Filter exact code search results by repository (Premium, Ultimate)

The new repo: syntax allows you to refine your code search by scoping queries to specific repositories or patterns directly. This enhancement removes the need to navigate into individual projects to find exact results.

By using a query such as def authenticate repo:my-group/my-project, the search is restricted to that specific location. You also have the flexibility to match multiple repositories simultaneously by using partial paths or patterns. Learn more here.

Configure work item types (Premium, Ultimate)

The introduction of configurable work item types allows you to tailor your workspace by creating or renaming entities to User Story, Bug, or Maintenance. Each item is clearly identified by its specific type name and a distinct icon, facilitating better visual organization. These new types are fully integrated with custom fields and status lifecycles, ensuring they appear seamlessly within your issue boards and saved views. Furthermore, configurations established at the organization or top-level group level (GitLab.com or GitLab Self-Managed) will automatically cascade to all sub-projects.

Administrators also have granular control over type availability on a per-project basis. You can choose to enable or disable specific types across the entire organization simultaneously, or grant individual projects the autonomy to manage their own visibility settings. Importantly, disabling a type within a project will not impact or alter any existing work items. Learn more here.

GitLab Secrets Manager now available in open beta (Premium, Ultimate)

The GitLab Secrets Manager has entered open beta, accessible to Premium and Ultimate tier customers across both GitLab.com and Self-Managed instances. Once activated, project and group Owners gain the ability to securely store, retrieve, and reference CI/CD secrets directly within GitLab. These secrets are precisely scoped to the project or group level, ensuring they remain accessible only to the specific pipeline jobs that explicitly call for them. Learn more here.

Improved array support for CI/CD inputs (all users)

Pipeline configurations are now even more versatile thanks to enhanced array support for CI/CD inputs. By utilizing the array index operator [], you can pinpoint and access specific elements within your array inputs directly. This improvement streamlines your interpolation workflows, allowing for precise referencing of individual items without the need for complex pre-processing. Learn more here.

Select multiple values for pipeline inputs (all users)

Pipeline execution becomes more flexible with the ability to select multiple values from dropdown menus in the UI. These selections are automatically aggregated into an array (e.g., ["option1", "option2"]), simplifying complex operations within a single run. This functionality is particularly useful for tasks such as:

• Restarting services across several instances simultaneously.
• Generating multiple Docker images at once.
• Executing tests using various tag combinations.
• Managing any process targeting multiple destinations at once.

Learn more here.

Configure parallel pipeline limits for merge trains (Premium, Ultimate)

The rigid restriction of 20 parallel pipelines within merge trains is now a thing of the past, granting you the flexibility to manage runner capacity without abandoning merge trains altogether. You can now fine-tune the parallel pipeline limit on a per-project or instance-wide basis to achieve the perfect equilibrium between runner demand and merge velocity. By adjusting this limit to 1, merge requests will process sequentially against an pristine target branch, ensuring stability while optimizing your infrastructure. Learn more here.

Cross-project pushes using CI/CD job tokens (all users)

While previous GitLab versions restricted the CI/CD job token (CI_JOB_TOKEN) to pushes within the same repository, cross-project pushes no longer require a personal access or deploy token.

You can now leverage a job token for pushes to external projects, provided the following conditions are met:

• The destination project has explicitly opted in.
• The user initiating the pipeline holds at least a Developer role in that target project.

Please note that this functionality is managed by the allow_push_to_allowlisted_projects feature flag. It is disabled by default in GitLab 19.0, so you will need to coordinate with us to enable it. Learn more here.

Dependency scanning by using SBOM generally available

With the general availability of GitLab’s SBOM-based dependency scanner, projects using Maven, Gradle, and Python now benefit from exhaustive visibility across their entire dependency landscape. This advancement ensures that vulnerabilities within the full dependency tree are identified, capturing transitive packages that were previously hidden and not just those explicitly declared.

A key feature of this release is the automated dependency resolution for Maven, Gradle, and Python ecosystems. In scenarios where a resolved dependency graph or lockfile is missing, the analyzer autonomously triggers the necessary tooling to map out the complete transitive graph prior to the scan. This capability is active by default, offering a seamless experience that typically requires no extra setup beyond the inclusion of the v2 Dependency Scanning template.

In instances where full dependency resolution cannot be achieved, the system intelligently reverts to manifest scanning. By analyzing files such as build.gradle, build.gradle.kts, requirements.txt, and pom.xml, the scanner identifies all direct dependencies. This fallback mechanism guarantees that teams maintain a foundational level of vulnerability intelligence, even when specialized build or lock files are absent.

While manifest scanning is enabled by default to surface direct dependencies, achieving comprehensive transitive coverage is straightforward. Teams can either utilize the automated dependency resolution feature or provide a manually exported dependency graph or lockfile to ensure no vulnerability goes unnoticed. Learn more here.

Admin-defined network access controls for Agent Platform remote flows

Security and platform teams now have access to a centralized governance layer for agent network egress through admin-defined network access controls. Instance administrators on GitLab Self-Managed and Dedicated, alongside top-level group administrators on GitLab.com, can manage these policies directly within Settings. The system allows for the configuration of organization-wide domain allowlists and denylists that are automatically inherited by all projects. While these policies are enforced at runtime for all GitLab Duo Agent Platform remote flows, an additional control determines if individual projects can augment the approved list with their own custom entries. Learn more here.

Dependency scanning in security configuration profiles

Expanding on the security configuration profiles introduced in GitLab 18.11 for SAST and secret detection, dependency scanning is now integrated via the Dependency Scanning - Default profile. This update provides a centralized control surface for applying consistent SCA coverage across all projects, eliminating the need to modify individual CI/CD configuration files.

Standardized scanning is now driven by two automated triggers:

• Merge Request Pipelines: Dependency scans execute automatically whenever new commits reach a branch with an active merge request, highlighting only the vulnerabilities introduced by those specific changes.
• Branch Pipelines (default only): Scans run automatically upon merges or pushes to the default branch, ensuring a continuous and comprehensive overview of your primary dependency security posture.

Learn more here.

Dependency resolution for Gradle SBOM scanning

For Gradle-based projects, GitLab's SBOM-powered dependency scanning has been enhanced to automatically produce the required dependency graph (gradle.graph.txt). This eliminates the former requirement to manually generate this graph during the build phase. Java and Kotlin developers using Gradle will now find that the analyzer autonomously creates the graph file whenever it is missing, streamlining the scanning process. Learn more here.

Remediation guidance for API security testing findings

Vulnerability reports for API security now feature integrated remediation guidance for every identified finding. While previous security testing highlighted vulnerabilities, developers were often left to manually research how to address them. This update removes that hurdle by providing specific remediation steps alongside direct references to CWE and OWASP identifiers within the report itself.

The following checks now include this comprehensive remediation guidance:

• Application information
• Authentication token
• Cleartext authentication
• CORS
• DNS rebinding
• Framework debug mode
• Heartbleed OpenSSL vulnerability
• HTML injection
• Insecure HTTP methods
• JSON hijacking
• JSON injection
• Open redirect
• OS command injection
• Path traversal
• Sensitive file
• Sensitive information
• Session cookie
• Shellshock
• SQL injection
• TLS configuration
• XML injection

Learn more here.

Detailed CI/CD Catalog component usage analytics

Effective management of CI/CD components within the GitLab Catalog depends on having clear visibility into usage patterns, which is essential for coordinating upgrades, maintaining compliance, and announcing breaking changes. Without knowing exactly which projects are using specific components or which versions are active, it can be nearly impossible to contact the appropriate maintainers, manage deprecation cycles safely, or confirm that all projects have applied vital security updates.

The newly introduced component usage view on the catalog resource page addresses this by identifying every project utilizing a component and specifying its current version. By highlighting projects running outdated versions at the top of the list, the interface allows you to streamline your outreach efforts, accelerate the adoption of security patches, and facilitate a consistent upgrade strategy throughout your entire organization. Learn more here.

Future updates will eliminate notifications triggered by @mentions in commit messages. Based on feedback from maintainers that these alerts are seldom helpful, this adjustment aims to streamline your notification feed and minimize unnecessary interruptions.

The REST API endpoints for listing Dependabot alerts at the enterprise, organization, and repository levels are phasing out the first, last, and page parameters used for offset-based pagination. You should transition to cursor-based pagination by utilizing the before, after, and per_page parameters instead.

GitHub is reserving the /repos path for an upcoming product feature to maintain compatibility with GitHub Enterprise Server. If your current routing—whether for a Username, Organization, GitHub App, OAuth application, reverse proxy, or internal integration—utilizes /repos, you might need to adjust your setup to prevent potential conflicts. This update guarantees consistent performance for GHES 3.20 users and prevents unintended request handling for any endpoints located under the /repos path.

To streamline governance throughout the enterprise, owners now have the ability to establish and oversee enterprise teams. Through the enterprise settings UI or the API, owners can link these teams to organizations, develop bespoke enterprise roles, and allocate roles to both users and teams. This update allows repository and organization owners to grant roles to enterprise teams within their designated scope, while also enabling the addition of enterprise teams to ruleset bypass lists. Please note that this experience currently includes certain product limitations. As a public preview feature, these functionalities remain subject to further refinements. Learn more here.

Self-hosted runner flexibility is enhanced as organizations can now define custom runner labels for Dependabot jobs. Furthermore, Dependabot has expanded its ecosystem support to include version updates for Conda packages.

By default, repository administrators can install GitHub Apps that do not necessitate organization-level permissions. To enhance security and strengthen compliance governance, organization owners now have the ability to restrict these installations, ensuring that only they can authorize new apps.

Even if GitHub Actions policies at the organization or repository level typically restrict the uploading of workflows, administrators can now utilize default setup to enable code scanning. This update ensures that security scans remain functional and are not obstructed by Actions policy restrictions. Learn more here.

Shipped with this release is CodeQL CLI version 2.23.9, powering the CodeQL action for advanced code scanning. Since the version provided in GitHub Enterprise Server 3.19, several major enhancements have been introduced:

Language and Framework Enhancements

• Rust Support: Rust analysis is now generally available, allowing developers to secure libraries and applications against all OWASP Top 10 categories, excluding A06:2021.
• Swift & Kotlin Updates: CodeQL now includes support for Swift versions 6.2 and 6.2.1, alongside Kotlin releases 2.2.0x and 2.2.2x. Note that support for Kotlin 1.6 and 1.7 is being phased out.
• C/C++ Buildless Scanning: Analysis for C/C++ projects without requiring builds is now generally available, with a new default "none" build-mode to simplify adoption for new repositories.

Performance and Workflow Improvements

• Incremental Analysis: To boost performance, CodeQL now supports incremental analysis across all its supported languages.
• Action v4 Migration: Advanced setup users must transition to CodeQL Action v4 (running on Node.js 24) before v3 is retired in December 2026; default setup users will be migrated automatically.