We moved our Bugbot setup from reviews per-user to a central team account that covers all repository. Since then only my own PRs stopped being automatically reviewed when they are open, even though requesting through a comment goes to the correct account.
I have tried disconnecting the Github integration from my own account and changing the settings with no avail.
Steps to Reproduce
Set up a github integration and bugbot with review on open for an individual account
Set up a central team account with same settings for the whole repository
Open a PR with the owner of the initial account
Expected Behavior
The automatic review should be trigger for all accounts in the repository.
Operating System
Other
Version Information
Cursor Agents
For AI issues: add Request ID with privacy disabled
ID from 2 days ago: serverGenReqId_8f40f4a1-8ee0-4361-ab39-f04eb7fd7ff8
ID from today: serverGenReqId_155df7a7-fe4a-44b9-901a-d1ce85db4453
Additional Information
In the PR from today’s ID the Security Reviewer also ran although it’s not enabled in either of the accounts.
Hey, @luispowerus. We figured out what’s going on. It’s about how Bugbot picks settings for a specific PR.
When a PR is opened, Bugbot applies the personal Bugbot settings of the Cursor account that the PR author’s GitHub login is linked to. Your GitHub login is currently linked to the central team account, not your personal one, and that account’s personal Trigger Mode is set to Manual Only. That’s why your PRs wait for a comment, while everyone else’s reviews start automatically. That’s also why changing settings on your personal account and disconnecting GitHub didn’t change anything.
Quick fix:
Log in to cursor.com using the central team account.
Open the Bugbot page in the dashboard and switch to My Settings (Personal Preferences).
Change Trigger Mode from Manual Only to Every Push, or Once Per PR if you prefer.
Open a test PR and confirm Bugbot starts on its own.
Long term, it’s better to link the central account to a separate GitHub user, like a bot or service account, instead of a personal GitHub login, and then reconnect your GitHub to your personal Cursor account. Otherwise, the central account’s personal settings like PR summaries, draft handling, and so on will keep applying only to your PRs.
About Security Reviewer: it really is configured on the central team account Dashboard > Security Agents, so it’s not coming from your personal account. Please send the link to the PR comment where you saw it so we can check what triggered it.
Thank you Dean! I completely missed the personal settings for the shared account, that explains everything. I’ll look into setting up a different account, thanks for the suggestion!
About the Security Reviewer:
PR #25939 with check run id 106766588753
PR #25952 with check run id 106736134133
When I go to the dashboard I see runs happening the 21st and 22nd of September but, to my knowledge, we have not enabled it.
Re Security Reviewer, it’s the same idea as with Bugbot. Security Reviewer is a Cursor-managed automation, and it’s configured on the central team account, not your personal one. Since your GitHub login is currently linked to that central account, its Security Agents configuration also applies to your PRs. That’s why you’re seeing runs on PR #25939 and #25952 even though you didn’t enable anything on your personal account.
You can check and disable it if needed like this:
Log in to cursor.com using the central team account.
Open Automations > Security Dashboard > Security Agents.
You’ll see an active Security Reviewer there. You can turn it off, or limit it to specific repositories if you don’t need it right now.
Once you move the central account to a separate GitHub user bot or service account like we discussed above, this confusion will go away. Its personal settings and Security Agents config will stop applying to your PRs.
Let me know if anything doesn’t match after you check the configuration.
About the contradiction in the screenshots: these are two different things, and they really do look like they conflict.
The third screenshot (the table with the agent) shows a specific Security Reviewer set up on the central team account. It’s shown as Enabled, with 7/7 checks and the PR Opened / PR Pushed triggers. This agent is the source of the automatic runs you saw on PR #25939 and #25952 on September 21-22.
The second and first screenshots (the “Security Agents are disabled…” banner and the “Security Disabled” card with the Enable button) are a separate team-level control.
The fact that one screen shows the agent as Enabled while another shows the feature as Disabled looks contradictory, and it shouldn’t happen. I’ve shared this with the team so they can look into the inconsistent UI state.
To help me separate the real state from a possible UI bug, can you confirm two things:
Were all three screenshots taken under the same account (the central team account), or under different accounts?
Where is the table with “Security Reviewer / 7/7 checks / Enabled” located? Is it under Automations > Security Agents, or somewhere else in the dashboard?
If you just need to stop these runs right now: log in as the central team account, go to Automations > Security Agents, and disable the Security Reviewer in the table, or limit it to specific repos. Once you switch the central account to a separate GitHub user (bot / service account), like we discussed earlier, its configuration will stop applying to your PRs.
Let me know the answers to the questions above and we’ll go from there.
Yes all of the screenshots above are taken under the same team account
This table is located in Automations > Security, it is the first item right under the analytics
I will disable this agent as you suggested, that would be enough for us.
Thank you very much for the quick support!
Edit: I tried disabling the agent but I can’t without enabling the global security. I get the same banner “Security Agents are disabled. A team admin must enable them in the team settings” and the Configure button doesn’t do anything.
I went around that by enabling security, removing the agent and disabling it again.
Hey, glad we got the settings sorted out, and that you found a working workaround to disable the agent.
About the UI behavior. What you described (the agent shows as Enabled in the table while the banner says “Security Agents are disabled”, you can only disable the agent after turning global Security on first, and the Configure button doesn’t respond) shouldn’t happen. It’s not something in your setup. I’ve passed this to the team to look into the inconsistent state. I can’t share an ETA yet, but if I get an update, I’ll reply here.
Net result is your config is in the right state now. The agent is removed, Security is off, and automatic runs on your PRs shouldn’t trigger anymore. If you see it run again, please send a link to the PR comment and we’ll check it.
And like we discussed earlier, long term it’s best to link the central account to a separate GitHub user (a bot or service account) instead of a personal login. After that, the central account’s personal settings (Trigger Mode, PR summaries, Security Agents, etc.) will stop applying to your PRs, so this kind of confusion won’t happen.
