This is a follow up to this thread that was closed with no acknowledgement for some reason: GitLab integration support
We were very excited to try Cloud Agents but were disappointed because right now the integration with Gitlab feels very rough, the onboarding process doesn’t work because it checks for Github access (https://forum.cursor.com/t/gitlab-cloud-agent/143689/38) and the Cloud Agents require an account with a “Maintainer” access level.
This feels like an unreasonable demand as this is the equivalent of asking for an admin access to our repos which when you’re working on a company scale isn’t really acceptable for obvious security reason. We can’t just give admin access to our team members. From my understanding the reason for this is that you will create Service Accounts on the fly for each request (or user?)? This is also not ideal because it will flood our repos with service account users that we can’t easily remove.
The ideal workflow to make the feature useful and usable for a team using Gitlab would be to configure one Service Account for the Cursor Team that will then be used for any cloud agent request. As it stands while the integration might be usable for individuals I don’t expect any team of developers to be able to use it properly in a production environment.
Happy to help and provide more info if needed to better this integration!
The previous thread was auto-closed as there had been no activity in the last one month, and that shouldn’t have happened. I apologize for that.
On the Maintainer requirement: we recently shipped a fix so that Developer-level GitLab users can now see and select repos in the repo picker (previously, only Maintainers could see them). However, the initial setup — creating the project access token and webhook on a repo — still requires Maintainer access, which is a constraint of GitLab’s API for project access tokens.
The concerns about per-user service account creation and bot proliferation are valid and something I’ve heard from multiple teams. A team-level service account model (one configured bot for the whole Cursor team, rather than tokens created per-user per-repo) would make this much more practical for production use. That feedback is noted and helps our team understand what’s needed for GitLab teams at scale.
For the separate issue where Cloud Agent creation fails with a GitHub credentials check — that’s tracked in the main GitLab Cloud Agent thread and our team is working through the remaining integration gaps.
Is there an issue we can track to monitor progress on this? Our company is using legacy privacy mode due to this issue and this keeps us from doing any cloud agent workflows.
Maintainer access requirement for env setup is too much. I ran into this issue here and had a whole different thread about it trying to figure out the problem ( Cursor onboard not showing repositories ).
At the very least the error message should be a bit clearer.
Surely somehow a Developer who can clone and work in a repo can set up a Cursor cloud env with their current permissions?
Cursor bot proliferation is unhelpful - is there a different thread for this already I should chime in on?
I literally just tried it this morning a few hours ago and couldn’t until I was given Maintainer permissions
To clarify - you can USE cloud agents with Developer access, but you can’t init/create the environment initially without Maintainer (from what my testing/experience showed this morning and past days).
@raphael-yapla can you confirm you can CREATE a Gitlab environment for a new repo with only Developer role? If so, maybe they changed something in past hours or else there is something strange going on.
Since gitlab is infering all the CI_JOB_TOKEN permissions from the user that pushed it (most secure way), I’m missing access to:
CI Templates from other projects
Docker images from other projects
npm packages from other projects
nuget packages from other projects
I can think of even more things that won’t work with a single project token. The only real solution I see, is to provider a predefined gitlab service account from my group, where I can finetune everything (which sub projects, which roles etc.).
