GitLab integration support

Ideas Feature Requests
, ,
1

Describe the Bug

We were trying to use the GitLab integration in order to have CloudAgents with our GitLab Premium.

But there were some catches that made it not usable:

  • not central “connect” for the org, which would require every single user to connect
  • requires at least Maintainer user
  • creates Cursor project token
  • consequently creates bot all around

With that in mind and comparing with desired scenario, I see it would be great if it supported over a single ServiceAccount.

Then it stays with 1 single bot and the access across the projects stays at our side.

I was wondering if a global team secret could be created providing the GitLab ServiceAccount token and taking precedence over project token.

Any chance an undocumented team secret that provides this functionality?

If not could we keep it as a feature request to support GitLab ServiceAccount?

These are the errors I’ve collected when trying to use a Developer user.

{
    "error": {
        "message": "Error",
        "details": [
            {
                "error": "ERROR_BAD_REQUEST",
                "details": {
                    "title": "Bad Request",
                    "detail": "Failed to create service account tokens and webhooks.. If you are on a GitLab free plan, please upgrade to Premium or Ultimate. Project access tokens are not supported on GitLab.com free plans.",
                    "isRetryable": false,
                    "additionalInfo": {},
                    "buttons": [],
                    "planChoices": []
                },
                "isExpected": true
            }
        ]
    }
}

{
    "error": {
        "message": "invalid_token",
        "details": [
            {
                "error": "ERROR_UNAUTHORIZED",
                "details": {
                    "title": "Unauthorized request.",
                    "detail": "invalid_token",
                    "isRetryable": false,
                    "additionalInfo": {},
                    "buttons": [],
                    "planChoices": []
                },
                "isExpected": true
            }
        ]
    }
}

Steps to Reproduce

Use GitLab integration with CloudAgents

Expected Behavior

  • better integration and central for all users of the org
  • Support for central ServiceAccount with low permission requirements, creating a single Cursor bot all around the org

Operating System

Linux

Version Information

Version: 2.3.35
VSCode Version: 1.105.1
Commit: cf8353edc265f5e46b798bfb276861d0bf3bf120
Date: 2026-01-13T07:39:18.564Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6 Likes
3

I would like to second on this one and suggest to review current GitLab integration for Cloud Agents, which seems to be sub-optimal in terms of required permissions and token usage for enterprises.

Context: Current integration implementation relies on creation of Project Access Tokens on each repository.

Problem: Minimum GitLab role required to create a project access token is a “Maintainer”, which is too permissive for common enterprise identity management models (allows editing repository settings, CI settings, env vars and secrets, delete tags, manage protected branches, etc). “Developer” role should be fully sufficient for Cloud Agents to work as it allows pulling code, working with branches and raise merge requests. The only reason “Maintainer” role is used - is to create project access token.

Another problem is that integration is user-specific, while common enterprise-grade approach is to rely on a central service accounts / bots to manage integration on organisation level.

4

Is there any update on this ? It’s impossible for our Cloud Agents to run any pipelines due to the integration being user based instead of service account based :frowning:

Because our (lets call it repo A) runs a pipeline, which includes a template from our template repository - the include causes the whole pipeline to fail because the bot user doesn’t have access to the template repository.

Solutions such as adding the user to the template repository, would be super brittle and not a solution - adding a job token doesn’t work either - Gitlab needs the user to be part of both repos - if the integration was based on Service Accounts, none of this would be a problem as far as I can see..

5

Hello there!

Do we have any update on this topic? Especially on the GitLab “Maintainer” role which is a security blocker for us (and for many companies I think/hope).

Thank you in advance for giving us more visibility on the roadmap :slight_smile:

2 Likes
6

Because some of our users in some projects are Maintainers, this is spreading many cursor token and bots all around :-/

We listed already 160, quite a mess

It would be great a proper support with central limited ServiceAccount