Do Cursor Automations run locally or in the cloud?

Cursor Automations are set up inside a normal local Cursor 3.8 agent session, but they run in the cloud. When the trigger fires, Cursor spawns a cloud agent that carries out the saved instructions on its own, so your machine does not need to be open for the automation to run.

What can a Cursor 3.8 automation do on its own?

A Cursor 3.8 automation runs a full coding agent unattended. The bundled starter templates, for example, triage a failed GitHub Actions run and auto-fix pull-request review comments. An automation can also open its own pull request and, with computer use on by default, hand back a demo or screenshots of the result.

Can you save a Cursor automation before it is finished?

Yes. Cursor 3.8 lets you save an automation while it is still incomplete and come back later — for instance, to set up MCP authentication — without losing your progress. You can also delete memory files from the UI, or tell the automation to delete its own outdated memories.

How are Cursor Automations different from GitHub Actions?

A GitHub Actions workflow is a YAML script; a Cursor 3.8 automation is a coding agent you describe in one plain-English sentence with /automate. It can read and edit your code, open a pull request, and use a computer to make demos, and it can fire on signals a YAML workflow cannot watch directly, like a Slack emoji reaction or a resolved review thread.

Cursor · 2026-06-18 · major

Cursor 3.8 — /automate skill plus new GitHub and Slack automation triggers

Cursor 3.8 launches Cursor Automations: describe a task in plain English with /automate and it runs on its own when a GitHub event or Slack emoji react fires. Adds five GitHub triggers; cloud agents get computer use by default.

Cursor 3.8 changelog cover graphic for the Improvements to Cursor Automations release

Describe a task in plain English and Cursor 3.8 turns it into an automation that runs itself when a GitHub event or a Slack emoji fires.

Quick facts

Version	3.8
Set up with	/automate skill — describe the task in plain English
GitHub triggers	5 — issue comment, PR review comment, review submitted, review thread resolved/unresolved, workflow run completed
Slack trigger	React to a message with a designated emoji
Cloud agents	Computer-use tool on by default — produce demos + screenshots
Starter templates	Triage failed GitHub Actions; auto-fix PR review comments
Also new	Save incomplete automations, auto-open PRs, delete memory files in the UI

What is it?

Cursor 3.8 adds Cursor Automations: saved agent workflows that fire on their own when an outside event happens, instead of waiting for you to type a prompt. You build one with the new /automate skill — describe the job in plain language and Cursor writes the trigger, instructions, and tool list for you, all inside a normal local agent session.

How does it work?

When a trigger fires, the automation hands the job to a cloud agent that works from the instructions you captured at setup, so nobody has to be at the keyboard. Those cloud agents now have the computer-use tool on by default, which lets them drive a browser or app and hand back a short demo or screenshots as proof of the work. A watched event can be anything from a GitHub review comment to a Slack reaction, and a finished automation can open its own pull request when it is done.

Why does it matter?

A Cursor agent used to wait for you to prompt it; an Automation starts from a teammate's signal instead — a review comment, a green CI run, a Slack emoji — so the work begins the moment it is needed rather than when someone remembers to ask. Because /automate builds the whole thing from one sentence, there is no YAML or glue code to write, so people who have never scripted a CI job can still stand up real event-driven agents. The bundled starter templates make the point: one triages a failed GitHub Actions run, another fixes pull-request review comments, both running unattended.

Who is it for?

teams running cloud-based coding agents on top of GitHub and Slack

Frequently asked questions

Do Cursor Automations run locally or in the cloud?: Cursor Automations are set up inside a normal local Cursor 3.8 agent session, but they run in the cloud. When the trigger fires, Cursor spawns a cloud agent that carries out the saved instructions on its own, so your machine does not need to be open for the automation to run.
What can a Cursor 3.8 automation do on its own?: A Cursor 3.8 automation runs a full coding agent unattended. The bundled starter templates, for example, triage a failed GitHub Actions run and auto-fix pull-request review comments. An automation can also open its own pull request and, with computer use on by default, hand back a demo or screenshots of the result.
Can you save a Cursor automation before it is finished?: Yes. Cursor 3.8 lets you save an automation while it is still incomplete and come back later — for instance, to set up MCP authentication — without losing your progress. You can also delete memory files from the UI, or tell the automation to delete its own outdated memories.
How are Cursor Automations different from GitHub Actions?: A GitHub Actions workflow is a YAML script; a Cursor 3.8 automation is a coding agent you describe in one plain-English sentence with /automate. It can read and edit your code, open a pull request, and use a computer to make demos, and it can fire on signals a YAML workflow cannot watch directly, like a Slack emoji reaction or a resolved review thread.

Try it

Update Cursor, then run /automate in any agent chat