Cloud Agents and Bugbot

Cloud Agents: spawning an agent over HTTP

Headless agent -p (the Cursor CLI’s non-interactive mode) runs the agent on your runner - your machine, your container, your CI minutes. Cloud Agents are a different primitive: full agents that run in isolated VMs in Cursor’s cloud rather than on your local machine, and that you can spawn programmatically over the API. The docs confirm both: “The Cloud Agents API lets you programmatically launch and manage cloud agents that work on your repositories” (API endpoints reference), and cloud agents “run in isolated VMs in the cloud with full development environments instead of on your local machine” (Cloud Agents documentation) - both as of September 2026. The naming is a known trap: these were called Background Agents and were renamed - “Cloud Agents were formerly called Background Agents” - so older forum posts saying “Background” mean the same thing, and the docs tree moved from the old /background-agent path to /cloud-agent with the rename.

Where the run executes is a field, not a fact. The create-agent API’s env.type picks the execution environment, and the endpoints reference spells out the values: “cloud uses Cursor-hosted VMs; pool and machine route to your own workers” (API endpoints reference). The umbrella label the main docs use for that second path is Self-Hosted Machines - hardware you manage, registered as workers that Cloud Agent runs land on. So “Cursor-hosted VMs” is the default story, not the only one: your org can keep the execution on machines it operates while keeping everything else about the primitive.

What you get over the API:

• Programmatic spawn - kick off an agent from a script, a webhook, or another service, not just from the desktop app.
• Model selection per agent - the create call takes a model object (a model.id from the models endpoint), falling back to your user default, then team default, then a system default when omitted.
• A pull request at the end - autoCreatePR (“Whether Cursor should open a pull request when the run completes”) brings the work back as a PR you review rather than a diff you have to go find. The cursor/... branch is a separate field’s doing: workOnCurrentBranch - “When false (the default), Cursor pushes commits to a new auto-generated branch (cursor/...)” - so commits land on a branch you already have only when you set it.
• Triggers that need no API call at all - the mention syntax is @cursor, uniform across hosts: “Use the @cursor command to kick off an agent” in Slack and Linear, “Comment @cursor on a GitHub PR or issue, or on a Bitbucket PR” on the code hosts. These mention triggers are documented on the Cloud Agents page itself.

Linear deserves the precise citation because it is easy to misdescribe: it is a first-party integration, not something you wire through an MCP server. Connect Linear under Cursor’s integrations (a Cursor admin authorizes the workspace), delegate issues to Cursor or mention @Cursor in comments, and “Cloud Agents show real-time status in Linear and create PRs automatically when complete” (Linear integration).

For budgetcli, the course’s illustrative personal-finance API, the Cloud Agents shape is the natural next step past CI: instead of a headless command that runs inside your pipeline, you fire an agent that runs in Cursor’s cloud (or on your own workers), on a clean clone, and comes back with a PR you review. It removes local filesystem risk, but it does not remove the cloud threat model: repository access, network access, secrets, prompt injection, trigger authorization, and retention still need explicit controls. Treat the returned pull request as a proposal, not proof that the cloud run was harmless.

That said, a Cloud Agent opening PRs against budgetcli is exactly the kind of access you scope deliberately - what repos it can reach, what it’s allowed to merge (it shouldn’t auto-merge), and which triggers can launch it. An open @cursor trigger in a Slack channel is convenient and is also a way for anyone in that channel to spawn an agent against your repo. Treat the trigger list as an access-control surface, not just a convenience.

Bugbot: an AI reviewer on every PR

The last surface inverts the relationship. Everywhere else in this chapter you start each run yourself - from a script, from CI, from the API - even when it then executes unattended. Bugbot is Cursor’s AI PR reviewer, and it fires without anyone initiating anything: you “connect your repositories through the Cursor dashboard,” enable it per repository, and from then on Bugbot “analyzes PR diffs and leaves comments with explanations and fix suggestions,” the way a careful human reviewer would (Bugbot documentation, as of September 2026).

Bugbot is not GitHub-only. The current docs list four supported providers: GitHub (including GitHub Enterprise Server), GitLab (including GitLab Self-Hosted), Bitbucket (including Bitbucket Data Center), and Azure DevOps (Azure DevOps Services) - each with its own integration page for the connect steps. If your forge is on that list, including the enterprise and self-hosted variants, support is explicit rather than assumed.

Where Bugbot earns its place in a CI chapter is the review result and any status check the integration exposes. A comment or an advisory review is not a gate by itself; if you want Bugbot to block merges, use the provider’s branch-protection or required-check settings, and verify what the integration actually reports before you rely on it. And keep team-wide invariants in the repository’s Rules rather than in a reviewer’s memory: Bugbot’s conversational learning commands are version-sensitive, so the standing facts should live in files the agent loads regardless.

One thing the docs are firm about and you should be too: Bugbot’s pricing is usage-based - it “first consumes your included usage, then bills additional reviews through on-demand spend” - and the specific numbers are version-fluid. Don’t quote a figure from memory; read it off Cursor’s pricing page at publish time.

The shape to carry out of the chapter

Editor for deciding, headless for scripting, CI for gating, Cloud Agents and Bugbot for the work that should happen without you at all. The discipline that makes the last two safe is the one this chapter has been building: the further the agent runs from your keyboard, the less you trust its flags and the more you trust where it runs, who can start it, and what it is allowed to touch. And every flag, format, command, and price here is version-fluid by design - the CLI was called a beta whose safeguards were still evolving, Cloud Agents were renamed once already, and Bugbot’s pricing moves - so confirm each against the docs cited inline before it goes into a pipeline you can’t watch.

That is the last new primitive in the course. Everything after this is about wearing the whole toolkit lightly - reaching for the right surface without deliberating first. Next: the daily workflow.