Cursor BugBot completed a review on a large PR (272 files changed, develop → main) in only 53 seconds, reporting “Successful in 53s — Bugbot Review” with no issues found.
This is highly suspicious. On smaller PRs with just 1–2 files changed, BugBot typically runs for 6–10 minutes. A PR with 272 changed files should take significantly longer to analyze, not faster. It appears BugBot may have skipped or short-circuited its analysis entirely, giving a false “all clear” on a very large changeset.
Have a GitHub repository connected to Cursor BugBot.
Open a large PR with many files changed (e.g., 272 files, develop → main branch).
Trigger BugBot review on the PR.
Observe that BugBot completes in ~53 seconds and reports no issues.
Compare with a small PR (1–2 files) where BugBot takes 6–10 minutes to complete.
Expected Behavior
BugBot should take proportionally longer to analyze larger PRs. A 272-file PR should be reviewed thoroughly and take several minutes (similar to or longer than small PRs). If BugBot cannot handle very large PRs, it should indicate this explicitly rather than returning a false “no issues found” result in under a minute.
Operating System
MacOS
Version Information
BugBot (GitHub integration) — version not directly visible. Cursor IDE latest version on macOS.
Hey, thanks for the detailed report. I get why 53 seconds on a 272-file PR looks suspicious, but in this case it’s expected behavior, not a skipped analysis.
BugBot runtime doesn’t depend on the number of files, it depends on how much real model inference it has to do. Before reviewing, BugBot filters out things that aren’t useful for review like lockfiles, binary and auto-generated files, node_modules/, dist/, very large files, and then it works on the remaining diff within a fixed budget. On merge PRs like develop→main, most of those 272 files usually get filtered out, so the effective diff is small and the review finishes quickly.
Because of that, sometimes a small PR with 1 or 2 files but non-trivial logic can take longer than a big merge. In that case the model does more iterations and pulls more context.
If you want to check what BugBot actually analyzed on this PR, leave a comment on it:
bugbot run verbose=true
This will start a fresh review with more detailed output and show what diff it used. If anything still looks like it was missed, send it here and we can dig deeper.
Also, on the free tier, the number of BugBot runs per PR is limited, so keep that in mind.
Hey, thanks for coming back with an update. That’s an important detail. If the first run said “no issues”, but after retries BugBot found real problems on the same PR, then my earlier explanation about diff filtering isn’t the main point here. This is inconsistency between runs. The result on the same PR can differ from run to run. This is known behavior, and it’s not how it should work. I can’t share an exact timeline for improvements.
If you hit this again and want us to look at your specific run, leave a comment on the PR:
bugbot run verbose=true
and send us the serverGenReqId_... from the BugBot response, especially from the run that returned nothing. With that ID, we can check the logs and see what happened on the first run.
Yeah, same thing. For a PR where BugBot, after a few runs, reports several irrelevant findings, leave this comment:
bugbot run verbose=true
and send me the serverGenReqId_... from the BugBot reply. If you can, also point out which findings are irrelevant. That way we can quickly check the logs to see what diff and context BugBot used, and why it flagged them.
Both cases, finding too little vs reporting extra stuff, are best debugged with a verbose run and the request ID. Send it over when you have it.