Cursor from bug report to pull request, one stage at a time

Last checked: 21 Oct 2026. The facts below come from Cursor's documentation, release notes, Marketplace automation templates and public Cursor Learn course, each linked where it is used.

A bug report can now reach a reviewed pull request through features Cursor documents: an automation picks up the report, a cloud agent writes the fix, Bugbot and the Security Reviewer review it, PR Routing & Approval finds a reviewer and Rollouts watches the deploy. Each is a separate decision with its own plan, platform and cost limits, so the order you switch them on matters most. Automate one step, prove it is reliable, then add the next, with a person approving every merge.

We use Cursor in our own engineering. The stage order and exit tests below are our recommendation, and what each feature does is Cursor's documented behaviour as at 21 Oct 2026. Cursor has been part of SpaceX since 14 Aug 2026, and our guide to SpaceX Super Intelligence (SpaceXSI) explains how it fits with Grok and Grok Bot.

The path from report to production, and what each step needs

First check that every step you want exists on your plan and your source control platform. This table is built from Cursor's own pages.

Sources: Automations, cloud agents, models and pricing, Bugbot, Security Agents, PR Routing & Approval and Rollouts. Release notes for the week of 7 Sep 2026 say the Security Reviewer now reviews Bitbucket pull requests, but the docs table lists Bitbucket as unsupported, so test it first. On our reading, the full chain needs Teams or above. Check your plan on Cursor's pricing page.

Before any automation: a repository an agent can test

Every later stage depends on the agent running your code. Cursor's set-up documentation says "Environment setup is the most important step to improve the effectiveness of your cloud agents." You can let Cursor's agent configure its own environment from the dashboard, or commit a Dockerfile referenced from .cursor/environment.json. The best-practices page adds: "If it is hard for a human developer to test locally, it will also be hard for an agent."

Our exit test: an agent started by hand can run the test suite and reproduce a bug you already know about. Our post on Cursor cloud agents and automations covers environment set-up and the full trigger list.

Treat every bug report as untrusted input

A bug report is text written by a customer or colleague, and the agent reads it. Cursor's cloud agent security page says cloud agents run terminal commands without stopping for approval, which "changes the risk model: an attacker who plants instructions in content the agent reads (a prompt-injection attack) could try to make the agent exfiltrate code to an external host." Internet access is on by default and can be restricted to an allowlist.

Automation memories persist between runs and are on by default, and the automations page warns that "Inputs may lead to misleading or malicious memories that unintentionally impact future automation runs." In our view a public bug form or busy Slack channel is that kind of input, so restrict network access before the first automated run and read the memory notes at each review. Our post on Cursor cloud agent security covers secrets, network access and audit logs.

A person starts the agent from the bug report

Start with no automation. An engineer hands a bug to a cloud agent using @cursor in Slack, a comment on a GitHub issue, Linear, the API or the web. The agent works on its own branch in an isolated virtual machine, and Cursor's security overview says it "opens a draft pull request for a human to review before anything merges", with signed commits. Agents attach screenshots, videos and log references to the pull request, per the capabilities page.

Cursor Learn's debugging chapter sets the rule: "If you can't reproduce the bug, you can't verify the fix." Our exit test: across a run of hand-picked bugs, the reviewer can explain every fix, each pull request arrives with evidence, and the team agrees which kinds of bug the agent handles well.

Automated triage with no access to code

The first unattended step should be one that cannot change your codebase. An automation set to "No repository" is the documented way to guarantee that: the automations page says it "cannot edit code or open pull requests." It cannot read the code either, so it suits duplicate checks, labelling, routing and posting a summary back to the thread.

Write the prompt as decisions. Cursor advises you to "Set a quality bar for when the agent should open a pull request, comment, or do nothing." Our exit test: over a few weeks, labels and routing match what an engineer would have chosen, and the memory notes hold nothing you would not want carried forward.

One narrow automated fix

Now connect a repository, on one trigger, for one well-understood class of bug. Opening a pull request is on by default: Cursor says "This tool is enabled by default for every automation." The documented hard limits are choosing no repository, or leaving approvals off so the agent "can only post comments" on reviews. A prompt telling the agent not to open a pull request is an instruction, and it does not enforce anything.

Cursor's own templates show the behaviour to copy. The Slack bug-fix template says "Only create a PR if you have a working fix." The Sentry investigation template says "Only implement fixes with high confidence in root cause" and otherwise to post the analysis to Slack with a follow-up plan.

Decide who the automation runs as. Per the automations page, run as yourself and it will "open pull requests as your GitHub account", making you the author under any rule that stops authors approving their own work. A service account, which only team admins can choose, opens them as cursor. Then check how the first agent-opened pull request arrives: the "Pull request opened" trigger does not fire on a draft until it is marked ready, and the Security Reviewer skips drafts. Pull request triggers also ignore pull requests from forks.

Starting narrow has outside support. An MSR 2026 analysis of 33,707 agent-authored pull requests on public repositories found that "agents excel at narrow automation (28.3% of PRs merge instantly), but frequently fail at iterative refinement". Our exit test: count every automated pull request as merged unchanged, merged after changes or closed, and read the closed ones before widening the trigger.

Automated review on every pull request

Bugbot runs automatically on each PR update and by default reviews only changes since its last review. The detail that catches teams out is that "Requiring the status alone does not block merges on findings because findings default to neutral." Blocking needs a fail-on-unresolved setting, where it is available to your organisation. As at 21 Oct 2026, test your branch protection with a deliberately flawed pull request. Our post on AI code review with Cursor Bugbot covers calibration.

The Security Reviewer checks pull requests before merge, and engineers can run the same check locally with /review-security before pushing. Cursor's own security team introduced its review bot in steps: its 16 Mar 2026 post says findings first went "to a private Slack channel monitored by our security team", then to pull request comments, and only then to a blocking gate. We would follow the same order for both review tools.

Letting the agent repair what review finds

Bugbot Autofix "automatically spawns a Cloud Agent to fix bugs found during PR reviews." Its modes are Off, Create New Branch and Commit to Existing Branch, the last capped at three attempts per pull request. GitHub and Origin support both, GitLab and Bitbucket only the second, and Azure DevOps neither. We would start with Create New Branch so a person sees each repair as a separate change. Cloud agents also try to fix CI failures on their own pull requests, for GitHub Actions only, and Cursor describes this as "currently only available on Teams".

Routing reviewers first, approval later

PR Routing & Approval "routes pull requests to the right reviewers and can approve low-risk changes", and Cursor says "It does not replace a full code review." Routing and approval switch on separately. It will not approve if Bugbot or Security Agents report findings that need human review, or if the pull request exceeds the risk threshold. A pull request that edits a policy file such as APPROVAL_POLICY.md cannot use the change to relax its own review.

Run routing alone until assignments are consistently right, then consider approval only for a narrow, written class of change. A person still sets the threshold, owns the policy files, reviews everything above it and answers for every merge. Our post on approval design for AI workflows covers who signs off.

After merge: watching the deploy

Rollouts checks a deploy when it happens and again after 20 minutes, 1 hour, 1 day and 3 days against your telemetry. It needs deployment events from your pipeline and at least one connected telemetry tool. On a regression it names the suspect change, opens an issue and notifies the author. Cursor's documentation says "Rollouts doesn't merge, revert, or roll back changes on its own", so a person decides what happens next.

Turning a repeated mistake into the right control

Each agent mistake should land where it will be caught next time, and the right file depends on which part of the chain failed. Cursor's rules documentation says to "Add rules only when you notice Agent making the same mistake repeatedly", and Cursor Learn's customising chapter warns that "Too many rules consume unnecessary context and may confuse the agent." Rules sit in the model's context and guide it. Hooks can enforce, and our post on Cursor rules, skills, subagents and hooks covers both.

One limit matters here: per Cursor's hooks documentation, hooks do not run during the read-only exploratory turns a cloud agent sometimes starts with.

Seeing what each stage did

Security Agents keep a run history showing "when an agent ran, which tools it used, its final status, and how long it took." Cloud agent runs have a Runs page filterable by trigger, status and creator, and a shared agent URL shows a teammate the conversation, code changes and artifacts, per the cloud agents overview.

There are gaps. Cursor's release notes for the week of 5 Oct 2026 say a failed Slack-triggered automation now marks the trigger message, but "The channel still gets no failure post." The same notes record fixes to quiet failures in these stages: "Incomplete reviews no longer auto-approve" (week of 5 Oct) and "Automations with more than one schedule now run on every schedule instead of only the first" (week of 28 Sep). Those are fixed, and they show why each stage needs its own check that it ran and finished, reported where a person looks. Our post on monitoring AI systems covers failures that do not crash.

Independent evidence is thin: we found no outside study of Automations, the Security Reviewer or PR Routing & Approval. A Carnegie Mellon preprint on agent pull requests argues that the team sets the outcome "through the expertise its humans bring and how it structures the review process."

What it costs and where the data goes

Every stage that runs an agent is separate usage. Automations "are billed based on cloud agent usage", Bugbot "uses usage-based billing", and Autofix "uses Cloud Agent credits". Cursor asks for a spend limit when you first use cloud agents, and on Teams additional usage pauses at the team limit until an admin raises it. Set the cap before widening any stage, and see Cursor's pricing page for current rates.

Cloud agents run in Privacy Mode, and conversation history is kept indefinitely by default. For UK teams, Cursor's privacy and data governance page says residency is US only, on Enterprise, with "EU + UK inference-only coverage" on request, and that the region of a Slack-triggered cloud agent cannot be guaranteed. That matters for a pipeline that starts in Slack.

Common questions

Can Cursor fix a bug and open a pull request without anyone writing code?

Yes, on a plan that includes cloud agents and automations. A repo-backed automation can open a pull request, and that tool is on by default. Cursor's documentation says cloud agents open a draft pull request for a person to review before anything merges.

Does Cursor Bugbot stop a pull request from merging?

Not by default, as at 21 Oct 2026. Findings default to a neutral check, so requiring the check alone does not block a merge. Blocking needs a fail-on-unresolved setting, where it is available to your organisation.

Can Cursor approve pull requests by itself?

PR Routing & Approval can approve low-risk changes if you switch approval on. It will not approve if Bugbot or Security Agents report findings that need human review, or above the risk threshold, and Cursor says it does not replace a full code review.

Which source control platforms does each step support?

Automation triggers work with GitHub, GitLab and Bitbucket Cloud. The Security Reviewer supports GitHub, GitLab and Origin per the current docs, with a conflicting release note on Bitbucket. PR Routing & Approval supports GitHub and Origin only. Bugbot has the widest support of the review features.

How do you stop an automation repeating the same mistake?

Put the lesson where the right part of the chain will read it: a short project rule for the coding agent, BUGBOT.md or a learned rule for Bugbot, and a hook for anything that must never happen. Cursor advises adding rules only for repeated mistakes.

If you want help deciding which of these stages your repositories are ready for, and building them in order, Request a Quote through our SpaceXSI implementation page.

John Kelleher holds the SpaceX Super Intelligence Partner Network Accreditation: Forward Deployed Engineer, and the SpaceX Super Intelligence Technical Architect Accreditation.