Cursor automation: pick the surface, then prove the result

Cursor automation means running Cursor’s agent with nobody at the keyboard: the Cursor CLI in git hooks and CI, Cloud Agents started by Automations on a schedule or an event, and the Cursor SDK or Cloud Agents API driven from a team’s own code. Rules and custom MCP servers feed every run, and tests and review gates decide what merges.

This hub is for developers and tech leads who want to hand recurring chores, such as the Friday dependency audit or docs that drift after API changes, to Cursor and still know the result is right.

What was checked, and when

Feature names were re-checked against Cursor’s docs on 2026-10-12 for the Cloud Agents, Automations and Projects rows below; the other names follow Cursor’s docs as read on 2026-08-28. Linked guides state their own checks.

Which Cursor automation surface fits your job?

Choose by trigger and reach: local services need your machine or runner; overnight jobs need the cloud.

Your job	Surface	Trigger	Read
Every run follows the same conventions	A tested Rules library	Loaded by the agent	Custom rules and templates
The agent needs your database or internal API	A custom MCP server	Tool call	Building custom MCP servers
A check at commit time or a step in your CI	Cursor CLI in print mode (-p)	Git hook, CI event, cron	Scripting the Cursor CLI
A chore on a schedule or on a Slack, Linear, Sentry, PagerDuty, webhook or source-control event	Cloud Agents started by Automations	Schedule or event	Cloud Agents and Automations
Tool execution must stay inside your own network	Cloud Agents on self-hosted machines (My Machines or Team pools, started with agent worker)	Not a trigger; sets where the agent’s tools run	Cloud Agents and Automations
One coordinating agent for a feature, a migration or a full app over months	Cursor Projects (beta)	Subscriptions: a Slack channel, a schedule or PRs	Cloud Agents and Automations
Your script, service or CI job launches and follows agents	@cursor/sdk (npm), cursor-sdk (PyPI) or the Cloud Agents API	Your code	The Cursor SDK and the Cloud Agents API
A second agent reviews every PR	Bugbot	Pull request	Bugbot
Low-risk PRs get routed and approved by rule	PR Routing & Approval	Pull request	PR routing and approval

In what order should you automate Cursor?

Each step reuses what the previous one proved; starting with an overnight Automation means debugging prompt, context, permissions and trigger at once.

1. Write down the proving command, such as pnpm typecheck && pnpm lint && pnpm test. It judges every later run, not the agent’s summary.

2. Fix the context. Put conventions in a small Rules library and give the agent MCP read access to the systems it keeps guessing about.

3. Make the interactive loop prove itself. Add a hook that runs the proving command when the agent finishes. Advanced Cursor techniques shows the setup.

4. Move one narrow job into CI with the Cursor CLI: read-only, no write token, output posted by a separate step.

5. Move recurring chores to Automations once the prompt has produced several good pull requests, starting on one repository.

6. Reach for the SDK last, when no built-in trigger fits, for example opening a fix PR when main goes red.

Copy-paste prompt: find your automation candidates

Read the project rules, package.json scripts, .github/workflows/ and the last 50 commit
messages. List up to eight recurring chores in this repository that a Cursor agent could
run unattended (for example dependency audits, flaky-test triage, docs drift after API
changes, changelog drafts). For each one give: the trigger (schedule, pull request, Slack,
Linear, Sentry or webhook), the files it would touch, the existing command that proves
the result correct, and a risk level (low: read-only report; medium: opens a PR; high:
touches release, infrastructure or secrets). Rank low-risk chores that already have a
proving command first. Do not change any files.

Before a chore runs unattended, write its run contract: allowed files, proving command, required evidence, stop conditions.

Copy-paste prompt: draft the run contract for one chore

Draft a run contract for this chore: <chore>. Output four sections.
1. Allowed paths: the files or globs the agent may change.
2. Proving command: the one command whose exit code decides success.
3. Evidence for the PR: that command's output, the changed files, a link to the run.
4. Stop conditions: stop and report instead of committing if the change would touch
   CI config, secrets or more than 10 files, or the proving command fails twice.
Do not change any files.

How do you verify automated Cursor output without reading every line?

Trust the gates, not the agent’s report. There are four layers:

• The run cannot merge. Branch protection requires a passing check and an approval; a prompt can be ignored, branch protection cannot.
• CI reruns the proving command on the commit the agent pushed. The agent’s pasted output is a claim; CI is the proof.
• A second agent reviews it. Bugbot “reviews pull requests and identifies bugs, security issues, and code quality problems” (Cursor docs, 2026-08-28). See code review in Cursor.
• The evidence travels with the PR: the contract’s report, the test output and a link to the run, as the evidence bundle defines.

The tech lead merges on that evidence and samples a few automation PRs weekly; an automation whose PRs keep getting closed is narrowed or switched off.

What breaks when Cursor runs unattended?

Symptom	Cause	Recovery
An outside contributor’s PR gets no automated review, or runs with secrets	Fork PRs need a different trust setup from same-repo branches	Review fork PRs in a CI job with no secrets (Scripting the Cursor CLI)
A Slack- or Sentry-triggered agent goes off-script	Untrusted text steered the prompt	Mark it as data; grant no deploy or merge rights
Cloud Agents fail on a new dependency	A stale environment	Rebuild the Cloud Agent environment (Cloud Agents and Automations) before touching the prompt
A PR-triggered CI job leaks a secret	The agent loaded config from the contributor’s branch next to CURSOR_API_KEY	Check out the base commit and pass the diff as text (agent identity and secrets)
The bill jumps after a quiet week	A trigger fires on every push	Trigger only when a pull request is opened, not on every push, and scope the Automation to one repository (token and cost management)

Where to go next with Cursor automation

Without project rules and MCP in Cursor yet, start there. Other tools: Claude Code, Codex, background and cloud agents and driving agents from code.

Start in CI

Script the Cursor CLI in hooks and GitHub Actions

Run it in the cloud

Cloud Agents and Automations

Drive it from code

The Cursor SDK and the Cloud Agents API

Govern it for a team

Privacy and security in Cursor