Cursor Bugbot Official Docs: Composer 2.5, /review, and Background Agent Governance

Cursor's June Bugbot update is attracting searches for the official Bugbot docs, background agents, and governance controls. The release matters because Bugbot — Cursor's automated PR review agent — now runs on in-house Composer 2.5, can be triggered with /review before code is pushed, and still respects team model block lists. The headline numbers are real: average review time fell from about five minutes to ninety seconds, cost per run dropped roughly 22%, and the number of bugs found per review rose from 0.56 to 0.62. But the operational question is not only "is Bugbot faster?" It is whether your Cursor docs, background-agent workflow, and model policy all describe the same code-review path.

What happened

Cursor's June 2026 Bugbot update ships three changes that matter:

• Composer 2.5 on the critical path. Bugbot previously composed its reviews from a mix of frontier provider models. It now runs primarily on Composer 2.5, Cursor's in-house frontier coding model that also powers the editor's agent loop. According to the changelog, the speed, cost, and recall improvements are all attributed to ongoing Composer 2.5 training.
• /review before push. Developers can run Bugbot and Security Review on demand from the agent before opening a PR, with /review-bugbot and /review-security shortcuts. The pre-push review syncs with the GitHub/GitLab Bugbot check on the resulting PR — same diff is detected and re-review is skipped. Cursor says this path is available in Cursor 3.7+ and on cursor.com/agents, with CLI support coming soon.
• Incremental review configuration. Teams can configure Bugbot to review only what changed since the last review on a given PR, rather than re-scanning the whole diff on every push.

The post is explicit that "speed and performance can vary depending on your configuration." That phrase, plus the model block list note, is doing real work: it acknowledges that some fleets will deliberately constrain Bugbot away from Composer 2.5. If your team is searching the Cursor docs for Bugbot background-agent behavior, treat that docs page as a policy surface: it tells developers how the review is launched, while the block list decides which model is allowed to read the diff.

Why it matters for AI engineering teams

The Bugbot update lands at the intersection of three things engineering organizations have been managing separately so far: code review, coding agents, and provider/model governance. Composer 2.5 collapses them into one decision.

• Code review is now a model-routing decision. Until this release, "which model reviews our PRs" wasn't a question most teams owned consciously. The vendor's default choice was good enough. Now that Cursor has put its own model on that path — and made it explicit that block lists override the default — the choice is back on the team's plate, and it has direct cost, latency, and IP implications.
• In-house vendor models are showing up on critical paths. Cursor is the most visible example, but the broader pattern is the same as Replit's Code Assist, Codeium's Cascade, GitHub Copilot's first-party models, and several Chinese coding agents that route to in-house models first. For routing operators this means: the model that touches your PR diffs may not be one your gateway is observing, billing, or auditing.
• PR diffs are sensitive payloads. A Bugbot review sees the full diff, surrounding files, and learned project rules from .cursor/BUGBOT.md. Whatever model handles that traffic gets a high-fidelity view of your codebase. Teams with code data residency, customer source restrictions, or contractual exclusions on which providers can see source code now need to confirm Composer 2.5's data handling matches their existing policy — Bugbot's block list is the lever for enforcing the answer.

The router/operator angle

Composer 2.5 on Bugbot is a useful forcing function to formalize a "code review model" policy alongside the existing "coding agent model" policy. A few concrete moves that travel well across tool vendors and gateway setups:

1. Treat code-review models as a separate routing class. "What we let write code" and "what we let read all our diffs at once" are different governance questions. The model that handles the second one should be on its own allow-list, with its own data retention, residency, and audit settings — not silently inherited from your editor's default.
2. Decide where Bugbot's block list slots into your existing controls. Cursor's block list is per-team, configured in the Bugbot dashboard. If your organization already maintains a central allow-list of approved providers — either inside your AI gateway, an internal policy doc, or both — Bugbot's block list should be derived from that source, not maintained by a separate admin in a separate UI. Pick the canonical source and propagate.
3. Decide what happens when Composer 2.5 is blocked. The changelog phrase "speed and performance can vary" is the hint: if your block list excludes Composer 2.5, Bugbot falls back to something else, with different latency, cost, and recall numbers. Run a baseline measurement of review time and bug yield with and without Composer 2.5 on a representative diff sample, and make the trade-off explicit instead of discovering it during an incident review.
4. Audit the data path, not just the model name. Composer 2.5 is hosted by Cursor, not by the frontier API providers most policies were written against. Procurement, security, and legal reviews written for "we use OpenAI and Anthropic for code" no longer cover the full surface area. Update DPAs, training-data opt-outs, and inference-region constraints to match.
5. Watch Bugbot's CI check posture. Bugbot publishes the Cursor Bugbot GitHub check with success, neutral, or failure conclusions. The default is neutral on findings, so a green build does not mean Bugbot signed off — it means findings are non-blocking. If you are tightening review policy around the new faster review window, decide explicitly whether Bugbot findings are required-for-merge or advisory.

The broader signal: tooling vendors are increasingly comfortable putting their own models on the critical path, and the contract with customers is shifting from "we wrap frontier APIs" to "we run our own model that you can opt out of." Block lists are the new opt-out surface. Treat them as a first-class routing primitive.

What TheRouter users should watch or try

If your organization runs a multi-IDE fleet — Cursor for some teams, Claude Code or OpenAI Codex for others, plus PR-side automation like Bugbot or CodeRabbit — the centralizing question is: where does the canonical "approved model" list live? A gateway is a natural place for that list because it sits between editors, CLIs, and PR bots, and can attribute usage per tool and per developer. As Composer 2.5 (and equivalents from other vendors) move more workloads off frontier APIs, the gateway's job shifts from "route every call" to "policy-check every call, route the ones that traverse the gateway, and audit the ones that don't." That second category is the one to instrument next.