We’ve had several issues with using bugbot against our self hosted gitlab issue.
The first reoccurring issue is that we select specific repos to enable for review, but this list will randomly change, suddenly all, or almost all, repos will be come enabled for no apparent reason, so we deactive all repos (we have about 300) and then have to re select the ones we want again.
This has occurred several times.
We’ve had bugbot just stop working alltogeather twice, where we had to delete and recreate the gitlab connection.
And finally our most recent pain. A new group of projects is just missing from the list. We have once again tried to delete and recreate the connection - but it would seem it never truly deletes the old connection from the cursor side. After deleting everything then recreating it, we can see a subset of repo’s pre-enabled that we had previously enabled, so obviously it’s remembering something.
In any case the problem remains, we have no way to enable our new projects for review because they dont appear in the list. There is nothing different or special about the new projects other than they are in a new group. Perhaps there is a limit of how many groups it will sync.
For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
Describe the Bug
Repositories in our self hosted gitlab do not appear in the list of available repostiories under bugbot. As such we cannot enable bugbot on some repositories.
Steps to Reproduce
We deleted our existing gitlab integration in cursor.
deleted the cursor application in gitlab.
created a fresh application in gitlab
created a fresh integration in cursor
synced repos
observe new repositories not appearing in bugbot. also observe that previous repository list shows, including what was previously enabled.
On the missing projects: the repo list only includes projects where the GitLab account that connected the integration has Maintainer or Owner access. There’s no limit on the number of groups. Each sync of your connection has been returning the same set of projects, so the new group isn’t being returned by GitLab for that account. Being a GitLab instance admin on its own doesn’t count; it needs to be a direct or inherited group/project membership.
Could you try this:
In GitLab, open the new group and go to Manage → Members.
Confirm the GitLab user you connected to Cursor is listed with the Maintainer or Owner role (add it if not).
In the Cursor dashboard, go to Integrations, open your GitLab Self-Hosted connection, and click Manage → Sync Repos.
Wait a minute, then open the Bugbot repository list and search for one of the new projects.
Do the new projects appear after step 4? If not, let me know the role your account has on that group and whether it’s a direct member or an instance admin.
On deleting and recreating: that now intentionally keeps your per-repo Bugbot settings, so you don’t lose your selections if you reconnect. You shouldn’t need to delete the connection to pick up new projects; Sync Repos is enough.
On repos suddenly becoming enabled: we couldn’t see what caused the earlier episodes. Right now “auto-enable new repos” is off for your connection and only the repos you selected are on. If it happens again, could you reply with the date and time (with timezone) you noticed it, and whether anyone had just reconnected or synced? That will let us trace it.
Despite having our repos enabled, and we can see API activity, bugbot is not reviewing anything now.
This has happened in the past and we fixed it by recreating the integration. I want to avoid attempting that again this time.
One thing worth noting is before we recreated the integration this time around we deleted all the access tokens and webhooks cursor previously created. (We noticed there were sometimes multiple cursor access tokens per project for some reason).
I can see cursor as added just an access token (or sometimes two) to some projects, just a webhook to others, and sometimes both an access token and webhook.
The two projects we noticed this morning with MRs not being reviewed have access tokens but no webhooks - is this the casue?
Hey @Kaitlyn, yes, that’s the cause. The webhook is how GitLab tells Cursor that a merge request was opened or updated. The access token is only used to read the code and post the review, so a project with a token but no webhook never gets reviewed.
Deleting and recreating the integration now keeps your per-project Bugbot settings, so some projects already showed as enabled when you reconnected. You never had to switch those back on, so Cursor never created a new webhook for them, and the old ones were removed during the cleanup. From what we can see, that applies to two projects (GitLab project IDs 283 and 393), which sound like the two you spotted.
To fix it without recreating the integration:
In the Cursor dashboard, open the Bugbot repository list.
Find project 283 and turn Bugbot off.
Wait a few seconds, then turn it back on.
In GitLab, open that project’s Settings → Webhooks and check that a Cursor webhook is now listed (pointing at api2.cursor.sh).
Repeat steps 2 to 4 for project 393.
Push a commit to an open MR in one of those projects, or open a new MR.
Does Bugbot review the MR after step 6? If any other enabled project isn’t being reviewed, check its Settings → Webhooks as well. If a project does have a Cursor webhook and still isn’t reviewed, open that webhook’s Recent events and let me know what response GitLab shows.
The extra access tokens are fine to leave in place. Cursor creates them when it needs project access, so a few can build up after repeated toggling. Going forward, it’s best not to delete Cursor’s webhooks or tokens by hand in GitLab. Cursor isn’t told when they disappear, which is how these two projects ended up stuck.
