GitLab Duo UI elements remain active when Duo is deactivated at instance/namespace/group/project levels

Summary

GitLab Duo UI elements and MCP tool usage remain active even when Duo is deactivated at various hierarchy levels, creating confusion and potentially violating subscription boundaries.

Steps to reproduce

  1. Deactivate GitLab Duo at any level (instance, namespace, group/subgroup, or project level)
  2. Navigate to a project where Duo has been deactivated
  3. Observe that the "Automate" section with "Agent sessions" and "Flow triggers" remains visible in the UI
  4. Click the "New session" button
  5. Notice it displays a non-functional Jenkins CI conversion panel
  6. Test MCP tool usage on the deactivated project
  7. Observe that embedded MCP continues providing tool usage despite deactivation

What is the current bug behavior?

When GitLab Duo is deactivated at any level:

  • The "Automate" section with "Agent sessions" and "Flow triggers" remains visible in the UI
  • The "New session" button is displayed but leads to a non-functional Jenkins CI conversion panel

Tackled separately:

  • The embedded MCP continues providing tool usage on deactivated projects (Known issue tackled separately)

What is the expected correct behavior?

When GitLab Duo is deactivated:

  • All Flow-related UI elements (Automate section, Agent sessions, Flow triggers) should be hidden
  • The "New session" button should not be displayed or should show appropriate messaging

Tackled separately in #568130 (closed):

  • The embedded GitLab MCP should respect Duo activation status at the project/group level and deny tool usage

Relevant logs and/or screenshots

Screenshots from a project in a .com duo deactivated group/project.
Screenshot_2025-09-05_at_17.55.10

Screenshot_2025-09-05_at_17.55.16

Possible fixes

  1. UI Consistency: Implement conditional rendering to hide Flow-related UI elements when GitLab Duo is deactivated
  2. MCP Integration: Update embedded GitLab MCP to check and respect Duo activation status at the project/group level before providing tool usage
  3. Consider implementing the same scope controls for Flows as exist for general Duo controls (as noted, currently Flows can only be managed at project level)
Edited by Sebastian Rehm