Bugbot says "disabled for this repository" for a repo the dashboard shows as enabled, while Approval and Security Agents run on it

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

The Cursor GitHub App is installed at organisation level, with selected repositories. Bugbot is configured from a Cursor Pro account. Under Automations everything looks right: Bugbot enabled, the organisation connected through GitHub, 1/1 enabled at 100% coverage, and the repository toggled on in the organisation view. Trigger mode is Once Per PR. Draft reviews are off.

Bugbot has never reviewed anything in this repo. Analytics says 0 PRs reviewed, and no commit has ever had a Cursor Bugbot check run. Meanwhile the PR Routing & Approval agent and the Security Agent run on the same repository and the same commits, posting their check runs within seconds of a PR opening. The app, the permissions and the events all work. Only Bugbot refuses.

Steps to Reproduce

Post bugbot run verbose=true in a PR’s Conversation tab and two replies land within a second:

Bugbot request id: serverGenReqId_…
Skipping Bugbot: Bugbot is disabled for this repository. Visit the Bugbot dashboard to update your settings.

Today’s request ids, 14 September 2026, UTC:

10:33 serverGenReqId_a4b92f78-a1a5-47c7-98dd-a620e0172d19, on a PR opened three days earlier
10:43 serverGenReqId_f45b4e0c-bc92-41a8-88aa-df4099fed355, same PR
10:55 serverGenReqId_00c453c7-d367-4656-8261-6a3141819b58, same PR, after toggling the repo off and on in the dashboard
11:02 serverGenReqId_642c2558-fefb-4576-a1aa-aa0a21cabda9, same PR, after disconnecting and reconnecting the GitHub integration
11:04 serverGenReqId_4dbfb6f3-1485-45f1-b848-d4852461a66a, on a brand-new PR opened after the reconnection; skipped on open and on the manual trigger
11:20 serverGenReqId_62fa226c-8f0d-4f91-83e1-5c4ef2756a7f, on a second brand-new PR, same result

Toggling the repository off and on in the Bugbot organisation page changed nothing. Neither did disconnecting and reconnecting the GitHub integration from the account that owns the Bugbot configuration. After both changes I opened two fresh PRs, so this is not the old-PR-stuck-on-stale-routing case from earlier threads. From the GitHub side, the organisation has exactly one Cursor App installation.

Why I think this is the known routing issue

Threads 151567, 154426 and 155829 report the same message, and in each case staff traced it to several members of one GitHub organisation having their own Cursor accounts with GitHub connected, so the request resolves under an account where the repository is disabled. Several of our engineers use Cursor individually, so we almost certainly meet that condition. I cannot see from GitHub which personal accounts are linked. Reconnecting from our side changed nothing, which fits the note in thread 153542 that disconnecting does not clear old account links on the backend.

Operating System

Other

Version Information

Cursor Agents

Additional Information

Could you check the routing for our installation and clear any stale account links? Failing that, could you tell me which Cursor account Bugbot is resolving the repository under, so we can fix it from there? The request ids above should identify the organisation and installation on your side.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report and the request IDs. That made it easy to trace.

There are no stale links on our side, and your GitHub App installation looks fine, so there’s nothing to clean up. What you’re seeing is how Bugbot works on the individual Pro plan. It only reviews PRs where the author is the GitHub account linked to the Cursor account that has Bugbot enabled.

For each PR, Bugbot checks the Cursor account connected to the GitHub user who opened the PR or who commented bugbot run, then it reads Bugbot settings from that specific Cursor account. Your engineers’ GitHub accounts are linked to their own individual Cursor accounts where Bugbot isn’t enabled for this repo, so those runs get skipped. The wording disabled for this repository is confusing in this case, and I’ve passed that feedback to the team.

Approval and Security agents run under the installation owner account, so they trigger on every PR. Bugbot doesn’t.

If you want Bugbot to cover all PRs in the org regardless of author, the supported path is Cursor Teams. Connect the org from the team dashboard and enable the repo there, then Bugbot will run for all contributors. As an alternative, each engineer can enable the repo for themselves in Agents → Automations → Bugbot, and then Bugbot will review their own PRs under their account.

One more thing. If you recently linked a second GitHub account to the Cursor account that has Bugbot settings, that won’t bypass this limitation. PRs from that account may pass the first check, but then get rejected because on the individual plan Bugbot only covers the account owner’s own PRs. If you comment bugbot run on that PR, the reply will show the exact reason.

More details on individual vs team here: Bugbot | Cursor Docs.

6

Thanks, that explains everything, and it’s working now that we’ve set it up the way you describe.

For anyone landing here with the same message: on an individual plan Bugbot checks the Cursor account linked to whoever opened the PR (or ran bugbot run), not the account that enabled the repository. So “disabled for this repository” really means “disabled for this author”. The Approval and Security agents don’t have that restriction, which is what made it look like a bug on our side. A different wording would have saved us a morning of reconnecting integrations and opening test PRs, so glad that feedback is going to the team.