GitLab broken CI on Cursor created merge request

Ideas Feature Requests
,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

In GitLab, when merge requests is opened by Cursor bot, or latest commits are by Cursor, the CI fails due to Cursor bot token having limited permissions. There are dependencies to other repositories in GItLab CI configuration file, that Cursor’s token has no access to.

This may be related to

The workaround is to push empty commit, but that’s contradictory to the idea of autonomous agent working. It’s especially annoying with Cursor cloud agents, because with local one I can just ask it to use my credentials for git work. This is also not ideal, because I want agentic work to be transparent and contribute to analytics as agentic workflow.

Steps to Reproduce

Have Cursor cloud agent do something, commit push and open merge request

Expected Behavior

CI not broken, no extra steps to continue with the usual flow

Screenshots / Screen Recordings

GitLabCIbroken.png
GitLabCIbroken.png2064×238 23 KB

Operating System

MacOS

Version Information

Mainly Cursor Cloud agents

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

There is a fault where the system saysYou have at least two unpaid invoices. Please click Billing & Invoices and pay them before changing your hard limit even though there are no outstanding accounts.

I sent an email got no response

Tried to send it to the forum got nowhere

What do I do?

7

This is a known limitation. Cursor currently creates project-scoped GitLab tokens for the bot user, which means the bot doesn’t have permission to access CI templates stored in other GitLab projects. When your pipeline uses include: to pull templates from external repos, it fails because of this scope restriction.

Our team is aware of the need for broader GitLab token scoping and it’s on our radar.

In the meantime, a GitLab-side workaround:

  1. In the dependent template project (the one your CI pulls templates from), go to Settings > CI/CD > Job token permissions and add your main project to the allowlist. This lets CI jobs from your project fetch templates even when triggered by the bot.

  2. Alternatively, create a group-level CI/CD variable (e.g., GROUP_TOKEN) containing a group-scoped deploy token, and reference it in your .gitlab-ci.yml for any cross-project include: directives.

Either approach lets your pipelines pass on bot-created MRs without waiting for a Cursor-side change.

Let me know if you run into issues with either workaround.