BugBot does look at the full PR diff (base to head), not just the last commit. The for commit ff58b91 bit is just saying which version of the PR it ran against, not that it only reviewed that one commit.
That said, there are some limits on how much of a large PR BugBot can fit into the model’s context. For the summary specifically, files from the diff are processed alphabetically by path, and there’s a cutoff: if the budget runs out partway through, files later in the alphabet won’t be covered in the summary. This shouldn’t affect bug detection, which handles large diffs differently.
I checked your request, and the diff was computed across all 110 files, so I’m wondering if that cutoff is what you’re seeing. Since the summary processes files alphabetically, things that sort early, like dotfiles (.gitignore, .env), config directories (.cursor/, .github/), or lockfiles, get processed first and can use up the budget before your actual source code is reached. We do exclude some common lockfiles like package-lock.json and yarn.lock from the review, but I can see your summary mentions bun.lock changes – that one isn’t currently excluded and could be eating into the budget here.
A few things that would help me confirm:
How many lines added/removed does GitHub show for this PR?
Are there other large generated files or lockfiles beyond bun.lock?
Is the repo public? If you can share the PR link we can take a closer look.
I mean it was a full stack feature in our frontend codebase and I expected bugs and it’s a little hard to believe that even after scanning the whole PR, there wasn’t a single nitpick bug. Bugbot is notorious for raising random tiny low severity bugs and saying it didn’t find any bugs is a bit unrealistic. This has happened multiple times in the past, its just the first time I am flagging it on the forum coz I was like this is an important PR and bugbot wasn’t able to review it.
Answers to your question:
Added 21,414 lines and removed 176 lines
No other file, it’s just a lock file at best (only 3 lines added in lock file btw). I do have 4176 lines in markdown plan docs that the agent wrote (using superpowers skills). Other files are just code files, all tsx or ts files. Your typical nextjs codebase.
Sorry it’s a private repo, can’t share a public link for it.
I have however noticed this whenever there are a lot of unit level commits in the PR, bugbot says I am not doing that. But when I have 3-4 huge commits, it works. I am not sure if that’s useful context but still sharing.
Also the reason I flagged this in reference to the summary is because that summary is actually only of the last commit I made. The summary is wrong and doesn’t capture the full PR. So I thought maybe it didn’t read the full PR. Coz I am assuming there is some relation of the summary and code it reviewed to raise the bugs. Everytime I get a tiny summary on something random like a doc file update it doesnt find bugs, making me think that its only considering the last chore commit I made.
Also if bugbot is a separate product we are paying for, I think it shouldn’t be limited to the context window of the model its using. If it’s just a special prompt you wrote and running it in one shot then there’s no point to paying for bugbot but if you are actually using a proper harness (which I believe you are), it should be able to handle large PRs as well given the fact that cursor has large enterprise customers as well. Coz its common practice to have really large PRs open against main for things like prod releases and stuff. Also I am able to get a clean simple summary but just using normal agent in the IDE, so not sure why bugbot cannot do if I can do it easily using composer model itself.
and says things like no issues found.
