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.
Just want to chime in - agree on two issues:
- 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?
With the recent update to environments the Gitlab integration seems to have been fixed and I can now use Cloud agents with a Developer level access!
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.
Yes with single repos no problem, I can create the environment with a Developer role straight from the website.
With multi-repo it just doesn’t work but I don’t know that it’s related to Gitlab, I created a separate topic for this.
Oh very interesting! Thanks for trying it again - I’ll attempt it as well again and see if results are any different from yesterday morning.
Nope, still same failure for me on a repo where I am only Developer:
Failed to get service account access token: Failed to get service account access token for any user.
