Performance degradation on subsequent Bugbot runs

Support Bug Reports
,
1

Typically, initial Bugbot runs finish within 30 minutes, but subsequent runs triggered by commits take significantly longer. Could you please look into request ‘serverGenReqId_713fd990-3539-4b3c-a267-cc73771fbf72’ ? It took 4 hours to complete. Thank you.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

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!

6

Hey @Haoze, thanks for the report and for including the request ID,!

I looked at that run. The review itself only took a few minutes of model time. The slow part was fetching your repository from your GitLab instance: each fetch took between 12 and 43 minutes, and a follow-up review (one triggered by a new commit on an MR that already has a Bugbot review) fetches the repo several times, because it compares the new commits against the previous review and re-checks the earlier comments. That pushed the run past our one-hour limit, so it was restarted a few times, which is where the 4 hours came from. The first review on an MR only fetches once, which is why those finish in about 25 minutes.

Two things you can do right now:

  1. Turn off “Incremental Review” (in the team settings, or your personal Bugbot settings). Follow-up runs will then review the entire MR in a single pass instead of making extra fetches.
  2. If you want fewer commit-triggered runs altogether, enable “Run Once Per PR” on the GitLab installation, or comment @cursor review on the MR when you want a review.

We are also working on making follow-up runs reuse the repository they already fetched instead of fetching it again.

One question so we can narrow this down: roughly how large is a fresh checkout of this repository (the size of the working tree, and whether it includes large binaries or LFS files)? That tells us whether the time is repo size or the connection to your GitLab host.