I have a Gitlab CI Pipeline for project A, that is importing a CI template from project B. If I now use Cursor Cloud Agents, it will set up a project access token on project A, which is only authorized for this project. Every push I now make, will fail the pipeline, since the project access token isn’t authorized for project B, where the CI template should be imported from.
I tried to use the environment.json with repositoryDependencies, but it doesn’t change the gitlab project access token. The approach of project access tokens anyway is very limitting here, since this is strongly scoped to a project and can’t be passed on to other projects.
In my case, everything is within the same gitlab group, which would make the use of service accounts on the group level possible, but this is very specific to my situation. I think it would be a more sustainable/flexible solution if it’s possible to specify for the cloud agents a specific service account with which the cloud agent should operate.
Or am I missing something? Is this already possible somehow?
On gitlab.com, Cloud Agents authenticate git with a per-project access token (the project_..._bot user), which GitLab scopes to that single project by design. repositoryDependencies only controls which repos get cloned into the agent’s VM (each with its own per-project token for the clone); it doesn’t change the identity that pushes your branch or that your pipeline runs as. And there’s currently no way to point Cloud Agents at a group-level service account on gitlab.com, so you haven’t misconfigured anything.
The pipeline failure itself is really a GitLab platform constraint. include: project: requires the user that triggers the pipeline to be a member of the included project, and GitLab doesn’t allow a project access token bot to be added to other projects (tracked upstream at gitlab-org/gitlab#361993). So the bot-created pipeline can’t read the template in project B, even though both live in the same group.
To unblock today:
Re-run the pipeline as yourself (a manual “Run pipeline” or an empty commit), so it resolves the include: with your own membership. Reliable, though manual.
If you want to keep it automated, the GitLab-side option is to stop relying on the MR author’s permissions for the cross-project import. For example, fetch the shared config at job runtime using a group access/deploy token stored as a CI/CD variable, rather than a native include: project:. Happy to dig into your specific setup if that’s useful.
One thing worth flagging: GitLab’s CI_JOB_TOKEN allowlist isn’t used for include: resolution, so allowlisting the project there won’t fix the template import specifically.
On your actual ask (letting the Cloud Agent operate as a specific service account): that’s a reasonable request, and for this exact cross-project include: case a service account is genuinely the right shape (GitLab recommends it for this too). It’s come up from other GitLab teams, and there’s an open thread discussing the team-level service account idea here: Gitlab integration requires unreasonable access for teams. Adding your use case there helps us gauge demand and prioritize.
thanks for your answer. The solution unfortunately isn’t that easy. It’s not just the missing project template, the CI_JOB_TOKEN is also missing other permissions, like docker images, nuget and npm packages from other gitlab projects. So working around this isn’t possible for us. The only solution I see here: allow custimzing the authentication with a gitlab service account. I’ll join the other thread for further discussions.
My current workaround is to have a change of the GitLab credentials during the install of the environment. So it logs in with other GitLab credentials and I restrain him to only push throug these credentials and create merge requests via the glab CLI. This sometimes works, but it’s not a stable solution. And also if I create merge requests through the glab CLI, they are not always detected by cursor and therefore cursor does not show the UI elements for merge requests as it would if it created the merge request through cursor.
So the final solution would still be to be able to define a service account for the integration of Cursor Cloud Agents with GitLab.