Enterprise
Cursor Cloud Agent Automations: Scheduled and Triggered Runs
Cursor Automations run cloud agents in the background, on a schedule or when an event arrives from GitHub, GitLab, Bitbucket Cloud, Slack, Linear, Sentry, PagerDuty or a webhook. Each automation pairs a trigger with a prompt, optional tools and a repository setting. Runs bill as cloud agent usage and use each model's maximum supported context window.
On this page
- What are Cursor Automations?
- How do I create an automation?
- What triggers can start an automation?
- How do Subscriptions differ from automation triggers?
- What tools can an automation use?
- How do repositories, permissions and identity work?
- How are automations billed, and how should I write prompts?
- Which marketplace automation templates are worth checking first?
What are Cursor Automations?
An automation is a saved cloud agent task that Cursor starts each time one of its triggers fires. You set it up once, and every run happens in the background without you. Cursor's docs split the setup into four parts.
- Trigger
- When it runs: a schedule, or an event from GitHub, GitLab, Bitbucket Cloud, Slack, a webhook, Linear, Sentry or PagerDuty.
- Prompt
- Plain-language instructions for what the agent should check, change or produce.
- Tools
- Optional capabilities such as Send to Slack, Comment on Pull Request or tools from an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server.
- Repository
- Whether the agent needs one repository, several repositories or none at all.
Cursor's own examples include automations that review recent PR commits for bugs, run a deep review for vulnerabilities, triage bugs reported in Slack, and summarize changes to your codebase on a schedule. Each example is a Cursor Marketplace template you can adapt instead of writing the automation by hand.
This is covered hands-on in Agent Mode Foundations — 6 short Units, free to read.
Rather do it than read about it? Run 11 interactive Cursor walkthroughs in a simulated editor. Free, no account needed.
How do I create an automation?
You can start an automation in four places: the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition., cursor.com/automations, the /automate skill in a local agent session, or a template in the Cursor Marketplace. With /automate, you describe the workflow in plain language and Cursor sets up the triggers, instructions and tools for you. Every path goes through the same five steps.
- 1Choose a trigger, such as every hour or when a pull request is opened.
- 2Write a prompt with instructions for the automation.
- 3Choose optional tools the agent can use, such as Send to Slack, Comment on Pull Request or tools from MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition..
- 4Choose whether the automation needs one repository, several repositories or no repository at all.
- 5Save and activate the automation.
What triggers can start an automation?
Automations start on a schedule or on an event from source control, Slack, a webhook, Linear, Sentry or PagerDuty. One automation can have several triggers, and it runs when any of them fires. Pick the trigger source before you write the prompt, because the source also decides whether the automation must have a repository.
Read Active vs Inactive on cursor.com/automations
0:19 · narratedRead this demo as text
- Automations live on cursor.com slash automations — not in desktop Settings. Mine shows Active and Inactive. Know which triggers can fire before you widen the allow-list.
Practice next: Practice this yourself in the hands-on module.
Simulated Cursor 3.12 (macOS, light) — beta educational reconstruction, not the real product.
- Trigger source
- Scheduled
- Fires on
- A recurring schedule from preset options or a cron expression. A run may start late, but never before the set time.
- Trigger source
- GitHub, GitLab and Bitbucket Cloud
- Fires on
- All three support draft opened, pull request opened, pushed or merged, push to branch, and comment added. GitHub adds label, issue, CI, review and workflow-run events. GitLab adds label changes and approvals, and Bitbucket adds approvals.
- Trigger source
- Slack
- Fires on
- A new message in a public channel, an emoji reaction, or a new public channel
- Trigger source
- Webhook
- Fires on
- A POST to a private HTTP endpoint that Cursor generates for the automation
- Trigger source
- Linear
- Fires on
- Issue created, status changed, or end of cycle
- Trigger source
- Sentry
- Fires on
- Issue created, issue updated, or any issue event
- Trigger source
- PagerDuty
- Fires on
- Incident triggered, acknowledged or resolved, or any incident event
| Trigger source | Fires on |
|---|---|
| Scheduled | A recurring schedule from preset options or a cron expression. A run may start late, but never before the set time. |
| GitHub, GitLab and Bitbucket Cloud | All three support draft opened, pull request opened, pushed or merged, push to branch, and comment added. GitHub adds label, issue, CI, review and workflow-run events. GitLab adds label changes and approvals, and Bitbucket adds approvals. |
| Slack | A new message in a public channel, an emoji reaction, or a new public channel |
| Webhook | A POST to a private HTTP endpoint that Cursor generates for the automation |
| Linear | Issue created, status changed, or end of cycle |
| Sentry | Issue created, issue updated, or any issue event |
| PagerDuty | Incident triggered, acknowledged or resolved, or any incident event |
Source: the triggers section of Cursor's Automations docs.
Slack triggers can see public channels only, for now. Without a message filter, a new-message trigger fires only on top-level messages, so add a keyword or regex filter if you also want thread replies. A webhook trigger has no URL until you save the automation. Saving generates the URL to call and an API key for authentication.
Pull request triggers don't run on PRs opened from forks. Those runs fail with a "Fork pull requests not supported" error, because the branch exists only on the fork and running outside code with the repo's permissions isn't safe. Pull request merged triggers still run, because they start from the merge commit. To work around the limit, push the branch to the repo itself and open the PR from there.
How do Subscriptions differ from automation triggers?
A subscription is the other way a cloud agent wakes on an event, and it belongs to one agent conversation. The agent subscribes to an event source, ends its turn, and wakes when a matching event arrives. The event lands as a follow-up in the same conversation, so the agent keeps its full context. Cursor introduced Subscriptions in its August 19, 2026 changelog and said they were available "for cloud agents only, for now." Cursor's Cloud Agent capabilities docs now have a section on them.
- Feature
- Set up by
- Automation
- You, once, with triggers, repos and tools, in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. or at cursor.com/automations
- Subscription
- A running cloud agent, when your prompt describes a wait or you invoke /subscribe. Per the changelog, an agent also subscribes on its own to each PR it opens.
- Feature
- Wakes on
- Automation
- Schedules and events from source control, Slack, webhooks, Linear, Sentry and PagerDuty (table above)
- Subscription
- Activity on one GitHub PR, CI results on a branch, Slack replies and channel messages, Linear issue events, or a timer
- Feature
- Runs until
- Automation
- Each trigger fires a fresh run
- Subscription
- The wait is over, or 180 days have passed, whichever comes first
- Feature
- Example
- Automation
- Triage failed GitHub Actions on every CI completion
- Subscription
- In Slack: "@cursor check back in an hour and keep going until that feedback is in"
| Feature | Automation | Subscription |
|---|---|---|
| Set up by | You, once, with triggers, repos and tools, in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. or at cursor.com/automations | A running cloud agent, when your prompt describes a wait or you invoke /subscribe. Per the changelog, an agent also subscribes on its own to each PR it opens. |
| Wakes on | Schedules and events from source control, Slack, webhooks, Linear, Sentry and PagerDuty (table above) | Activity on one GitHub PR, CI results on a branch, Slack replies and channel messages, Linear issue events, or a timer |
| Runs until | Each trigger fires a fresh run | The wait is over, or 180 days have passed, whichever comes first |
| Example | Triage failed GitHub Actions on every CI completion | In Slack: "@cursor check back in an hour and keep going until that feedback is in" |
Automation column from Cursor's Automations docs. Subscription column from the Subscriptions section of Cursor's Cloud Agent capabilities docs and the August 19, 2026 changelog.
Choose by where the rule should live. A repo-wide policy, such as triaging every failed workflow run, belongs in an automation, because it should exist apart from any one agent session. Follow-through on one piece of work, such as getting a PR through two rounds of BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. comments, is a subscription.
Subscriptions need an agent that a person owns. An automation set to run as a service account gets neither the /subscribe skill nor the subscription tools, so it cannot wait on a PR or a thread. The same release added /goal, which keeps the agent on one objective until it is complete, and Cursor suggests pairing it with /loop for recurring check-ins. The capabilities page covers the rest of that release.
What tools can an automation use?
An automation gets the same base tools as any cloud agent, plus the tools you enable for it. Pull request creation, memories and computer use are on by default. Check the GitHub and Slack tools before you enable them, because both can do more than post a message.
- Tool
- Pull request creation
- What it does
- Lets a repo-backed automation open pull requests after it changes code. PRs go to the trigger's repositories, or to the environment's for other triggers.
- Default
- On by default for every automation
- Tool
- Comment on pull request
- What it does
- Posts top-level and inline comments. With approvals enabled, it can also approve, request changes and dismiss reviews.
- Default
- Optional
- Tool
- Request reviewers
- What it does
- Requests reviewers on a target PR. The agent can use git, memory and other tools to find domain experts.
- Default
- Optional
- Tool
- Send to Slack
- What it does
- Sends messages to one channel or any channel. Allowing any channel also grants read access to discover public channels.
- Default
- Optional
- Tool
- Read Slack channels
- What it does
- Read-only access to list and read messages in public Slack channels
- Default
- Optional
- Tool
- MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server
- What it does
- Connects an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server. The agent can then use every tool that server exposes.
- Default
- Optional
- Tool
- Memories
- What it does
- Named notes the agent reads and writes across runs, stored as MEMORIES.md by default, outside the working filesystem
- Default
- On by default, can be disabled
- Tool
- Computer use
- What it does
- Lets the agent operate a browser, produce screenshots or recordings, or use internal services
- Default
- On by default for every automation
| Tool | What it does | Default |
|---|---|---|
| Pull request creation | Lets a repo-backed automation open pull requests after it changes code. PRs go to the trigger's repositories, or to the environment's for other triggers. | On by default for every automation |
| Comment on pull request | Posts top-level and inline comments. With approvals enabled, it can also approve, request changes and dismiss reviews. | Optional |
| Request reviewers | Requests reviewers on a target PR. The agent can use git, memory and other tools to find domain experts. | Optional |
| Send to Slack | Sends messages to one channel or any channel. Allowing any channel also grants read access to discover public channels. | Optional |
| Read Slack channels | Read-only access to list and read messages in public Slack channels | Optional |
| MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server | Connects an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server. The agent can then use every tool that server exposes. | Optional |
| Memories | Named notes the agent reads and writes across runs, stored as MEMORIES.md by default, outside the working filesystem | On by default, can be disabled |
| Computer use | Lets the agent operate a browser, produce screenshots or recordings, or use internal services | On by default for every automation |
Source: the tools section of Cursor's Automations docs.
Memories persist across runs, so use them with care when an automation handles untrusted input. Cursor warns that such input can create misleading or malicious memories that affect later runs. The agent can delete outdated memory files during a run, and you can view, edit or delete them from the tool configuration UI.
How do repositories, permissions and identity work?
The repository setting decides which code each run sees, and the Share menu decides who the automation runs as and who can manage it. For Slack and cron triggers, Cursor defaults to no repository. Source control triggers require at least one repo.
- No repository
- The agent does not clone code. Use it for workflows that only need Slack, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition., webhooks, Linear or PagerDuty. It cannot edit code or open pull requests.
- Single repository
- The agent works in one repository and branch, to read, review or change code in one codebase.
- Multi-repo environment
- The agent works across the repositories in an environment, for tasks that span several codebases.
On a team account, the Share menu on each automation holds two settings. Run as decides whose identity the automation uses, and Access decides who can see and manage it. Personal accounts have no Share menu.
- Run as: Me
- Runs with your auth.
- Run as: Service account
- Runs as a service account dedicated to the automation. Only team admins can choose it.
- Access: Private
- Other members can't see it. Only you manage it, and team admins can view and disable it.
- Access: Members can view
- Members can view it. You manage it when it runs as you, and team admins manage it when it runs as the service account.
- Access: Members can edit
- Members can view and edit it.
Switching Run as to Service account stops the automation from using your auth. If it has webhook triggers, regenerate its webhook API key after the change. If it uses MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers or other integrations that rely on personal OAuth credentials, configure them for the automation's service account instead. Only team admins can make the switch.
Cursor's automations docs say each automation set to Service account gets its own service account. Some older automations still share one team service account, and each moves to its own the next time it is saved. Cursor's help center still says the Service account option "runs as the team's shared account."
On GitHub, comments, review approvals and reviewer requests run as cursor. An automation that runs as you opens pull requests as your GitHub account, and one that runs as the service account opens them as cursor. Slack messages come from the Cursor bot.
How are automations billed, and how should I write prompts?
Automations create cloud agents and are billed as cloud agent usage. Because they run as cloud agents, they use each model's maximum supported context window, and there is no context-window toggle. Cursor's Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. docs note that a larger context window can increase token usage and costs.
The Run as setting also decides who pays. An automation that runs as you bills your usage. One that runs as a service account bills the team's usage pool and uses no member's personal usage. Personal accounts always bill to you.
Automations need a plan that includes cloud agents. Cursor's Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. docs list those plans: Premium and higher, Teams, Enterprise, or a legacy paid plan. Free and Plus don't include them.
Write the prompt the way you would brief any cloud agent run. Because an automation runs without anyone prompting it, the prompt has to settle each choice in advance, and Cursor's tips below show how.
- Be specific about what the agent should check, change or produce.
- Reference the actions you enabled. You can at-mention tools or mention their names informally.
- Include decision rules for what to do in different cases.
- Set a quality bar for when the agent should open a pull request, comment, or do nothing.
- Describe the output format you want.
Which marketplace automation templates are worth checking first?
Read a marketplace template before you write a custom automation from scratch. Two of Cursor's templates cover the review loop and the CI loop, and each template page shows the prompt it runs.
Start from a Popular automation template
0:17 · narratedRead this demo as text
- Popular templates already carry a trigger shape — Scheduled into Send Slack. Start from one that matches the manual run you already trust, then tighten the prompt.
Practice next: Practice this yourself in the hands-on module.
Simulated Cursor 3.12 (macOS, light) — beta educational reconstruction, not the real product.
- Autofix PR review comments
- Takes a first pass at inline review comments on a PR diff. It makes the smallest correct fix, pushes to the existing PR branch and replies on the thread. It does not open a new PR or approve the PR.
- Triage failed GitHub Actions
- Investigates failed or cancelled workflow runs and posts a summary in Slack. It defaults to triage only and opens a PR only when it has high confidence in a minimal fix.
Both prompts carry the decision rules Cursor's tips ask for. The autofix template tells the agent to reply and explain, not guess, when a comment is unclear or needs human judgment.
Frequently asked questions
Do automations run in Max Mode?
Only on legacy request-based plans, where Cloud Agents always run in Max Mode and are priced at API rates plus the Max Mode upcharge. Separately, Cursor's automations docs say automations use each model's maximum supported context window because they run as cloud agents, and there is no context-window toggle. Usage is billed as cloud agent usage.
Can an automation run without a repository?
Yes. For Slack and cron triggers, Cursor defaults to no repository, which suits workflows that only need Slack, MCP, webhooks, Linear or PagerDuty. With no repository, the agent cannot edit code or open pull requests. Source control triggers require a repo or several repos.
Is a Subscription the same thing as an automation?
No. An automation is a standing rule with triggers that you configure once. A subscription is a wait that one running cloud agent takes on, for example on a PR, a Slack thread or a timer. Cursor's August 19, 2026 changelog adds that an agent which opens a PR stays on it until the work is done, fixing CI and answering bot comments. Automations that run as a service account cannot subscribe.
Who does an automation act as on GitHub and Slack?
GitHub comments, review approvals and reviewer requests run as cursor. An automation that runs as you opens pull requests as your GitHub account, and one that runs as the service account opens them as cursor. Slack messages come from the Cursor bot.
Why does my pull request trigger fail on forked PRs?
Pull request triggers do not run on PRs opened from forks. They fail with a "Fork pull requests not supported" error, because the branch exists only on the fork and running outside code with the repo's permissions is unsafe. Pull request merged triggers are the exception. To work around it, push the branch to the repo and open the PR from there.
Sources & last verified
- Cursor - Cloud Agent Automations
- Cursor - Cloud agents overview
- Cursor - Cloud agent capabilities
- Cursor - Models and pricing
- Cursor - MCP
- Cursor Marketplace - Autofix PR review comments
- Cursor Marketplace - Triage failed GitHub Actions
- Cursor changelog - Cloud Agents and Cursor Harness Improvements (Aug 19, 2026)
- Cursor Help - Automations
- Cursor Help - Cloud Agents
Cursor ships frequently. Last updated October 28, 2026.