How to review Cursor background agent pull requests

A Cursor cloud agent hands you a branch from a machine you never saw. So the first question is about the checks. Cursor's documentation describes agents running in isolated sandbox VMs with their own development environments, configured through a saved snapshot or a Dockerfile named in .cursor/environment.json. A test that passed in there passed in there. Confirm your own CI ran on the branch before you spend attention on anything else.

Everything below was checked against Cursor's own documentation on 7 September 2026. This product changes quickly enough that an undated claim about it is not worth making.

What a Cursor background agent pull request is

Cursor renamed the feature: the docs page is now titled Cloud Agents and says they were formerly called Background Agents. The mechanics are the ones that matter for review. The agent clones the repository from GitHub, GitLab, Azure DevOps or Bitbucket Cloud, works on its own branch inside a sandbox VM that Cursor provisions, and pushes the result back for handoff, with supporting artifacts such as screenshots and videos.

It can be started from Cursor's desktop app, its web and iOS apps, Slack with @cursor, a GitHub or Bitbucket comment, Linear, or the API. That list matters for the review. The person who started this work may have done it from a phone, in a Slack thread you are not in, against an issue written by someone else.

The environment it ran in is not your CI

This is the one check I would add to the standard pass for these pull requests specifically.

The agent had a full development environment: it could install dependencies, run tests, and verify its own work. That is what makes cloud agents useful and it is also what makes their output easy to over-trust. The environment came from a snapshot or a Dockerfile committed to the repository, and those drift from your CI image. Green in the agent's VM and green in your pipeline are two different facts.

So: open the checks tab. If the branch has no runs, or the runs are older than the last push, nothing about this change has been verified anywhere you control. GitHub calls the general version of this CI gaming and puts it first among five red flags in agent pull requests. The Cursor case is gentler, usually accidental, and lands in the same place.

While you are in that neighbourhood, read the diff of .cursor/environment.json if it changed. A modification to the agent's own environment is a modification to what future agent runs will consider passing.

Artifacts are evidence, of one path

Screenshots and videos attached to the pull request are better than most agent output offers you, and they answer the last item on the checklist for agent-authored code: something ran, and here is what it looked like.

They answer it for the happy path. A recording of a successful upload says nothing about the upload that fails halfway, the second concurrent upload, or the upload from a user whose token expired mid-request. Take the artifact as proof that the main path works, then spend your trace on the branch that has no video: the failure branch.

Find out who asked for the change

Because a cloud agent can be started from Slack or Linear, the reason for a change often lives outside GitHub. Before you review intent, find the request. If the pull request body does not name the issue or the thread it came from, ask for it in a comment before you review anything else, because "does this change do what was wanted" is unanswerable without it.

This is the same gap GitHub names as agentic ghosting: the author was a process, and processes do not answer questions. With Cursor you at least have a person at the other end of the trigger. Find them.

What Bugbot covers, and what it leaves to you

Bugbot is Cursor's reviewer, and it is good at its job. Its documentation describes it analysing pull request diffs and leaving comments with explanations and fix suggestions, covering bugs, security issues and code quality, on GitHub, GitLab, Bitbucket and Azure DevOps. It can run automatically on every update or on demand with a cursor review or bugbot run comment, it reads the existing comments on the pull request so it does not repeat feedback, and it can spawn an agent to fix what it found, capped at three attempts when that fix commits to the existing branch, so it cannot loop forever. Effort is tunable across Low, Default and High, with a Smart setting that picks between them, and reviews can be incremental, covering only what changed since the last one.

Bugbot answers whether the change is wrong; it does not answer what the change is. Every finding is attached to a line in the diff, which means the reviewer still owns every question that has no line: whether this belongs in the codebase, whether it re-implements a service that already exists, whether the blast radius matches the title. Those are the expensive mistakes in agent work, and no line-anchored finder reports them. If you want that difference argued properly, PR Lens versus Cursor Bugbot is the long version.

Pricing, since people ask: Cursor's pricing page on 7 September 2026 lists Pro at $20 a month, Pro Plus at $60 and Ultra at $200, with Bugbot and cloud agents included on each, and the Bugbot docs refer to a May 2026 update to usage-based billing. Third-party round-ups quote different figures. Check the page.

Put your review rules where the tools read them

Bugbot takes rules at team level, repository level, and from a .cursor/BUGBOT.md file in the project, with limits documented at 30,000 characters per rule. That file is the right home for the review comments you are tired of writing by hand: which directories are generated, which patterns your CI already enforces, what counts as important in this repository against what is a nit.

It is worth keeping the same rules in .cursor/rules so the agent writing the code sees them too. A rule that only the reviewer reads gets applied after the mistake.

Get a picture of the change

The agent that wrote this pull request has finished and is gone, so the trick that works in a live session, asking the model to draw what it just did, needs a different route here. Two options.

If you have Cursor open on the repository, the PR Lens skill works as a rule. Install it with npx skills add coldteadotai/pr-lens, or copy SKILL.md from @coldtea/pr-lens-agent-skill into .cursor/rules/pr-lens.mdc, then ask Cursor to diagram the branch. It writes the graph document from the diff, validates it against the schema with npx @coldtea/pr-lens-cli validate, and renders the SVGs, using the model you already pay Cursor for.

If you would rather it happen without you, the hosted GitHub App draws every pull request in the repositories you pick and posts one comment that is redrawn on each push: new components in green, changed in amber, removed in red and struck through, with the untouched parts of the system still on the page. It sits alongside Bugbot in the same thread and answers a different question. PR Lens is open source, MIT licensed and free for open source repositories.

Then run the clock

With the checks confirmed, the request found and the shape in front of you, the rest is the ordinary pass: two minutes on the shape against the title, two on CI, configuration and deletions, four tracing one path including its failure branch, two on evidence. That is how to review a 400-line pull request in ten minutes, and the sizes justify the budget: LinearB's 2026 benchmarks put AI-assisted pull requests at 408 changed lines at the 75th percentile against 157 for unassisted ones.

For the same playbook with a live session at the other end, see how to review Claude Code pull requests. The method underneath both is in the complete guide to reviewing AI-generated pull requests.