Config-as-Code for Automations

Ideas Feature Requests
1

Feature request for product/service

BugBot

Describe the request

The problem

Automations are configured entirely through the web UI. This works fine for one or two, but as you add more, the cracks show:

  1. Not reproducible. You can’t fork a repo and get the automations with it. Setting up a second project, onboarding a teammate, or migrating to a new org means manually recreating every automation through the UI. Every other tool in this space – GitHub Actions, Vercel, Netlify, CircleCI – solved this years ago with config files.

  2. No branch-based testing. If you want to tweak an automation prompt or change a trigger, you change it live against production. There’s no way to test an automation change on a feature branch before merging. With config-as-code, Cursor could read the config from the branch that triggered the automation, letting you PR and review changes before they go live.

  3. No rollback. If an automation change breaks something, you can’t git revert it. You have to remember what the old config was and manually restore it in the UI. With a config file, rollback is a revert commit.

  4. Prompt drift. If you version-control your prompts in the repo (which you should – they’re code), you have to manually re-paste them into the UI after every change. If you forget, the change is silently ignored. There’s no sync mechanism and no error. The automation just keeps running the old prompt.

  5. No team visibility. One person changes an automation in the UI and nobody else knows until something breaks. Config-as-code means automation changes go through the same PR review process as everything else.

The proposal

An opt-in .cursor/automations.yml (or .json) file in the repo root. If the file exists, Cursor reads it as the source of truth. If it doesn’t, automations work exactly as they do today through the UI.

automations:
  qa-reviewer:
    enabled: true
    model: default
    trigger:
      type: github
      event: pull_request
      action: opened
    branch: main
    tools:
      - comment_on_pr
      - approve_pr
    prompt_file: .cursor/prompts/qa.md

  nightly-check:
    enabled: true
    model: default
    trigger:
      type: webhook
    branch: main
    tools:
      - open_pr
      - memories
    prompt_file: .cursor/prompts/nightly.md

Key behaviors:

  • prompt_file points to a file in the repo. When that file changes on the target branch, the automation picks up the new prompt. No manual re-pasting.
  • tools declares which tools the automation can use, reviewable in PRs.
  • trigger, branch, and model replace the UI dropdowns.
  • enabled lets you disable an automation without deleting its config.
  • Secrets (webhook URLs and keys) stay in the Cursor UI or environment – never in the config file.
  • Conflict resolution: the config file wins when present. The UI shows the file-defined config as read-only and links to the source file for edits. This is the same model Vercel uses for vercel.json overriding dashboard settings.

The UI remains the default way to create and manage automations. The config file is a power-user opt-in for teams that need version control, review, and reproducibility.

Why this matters

Automations are the most interesting feature Cursor has shipped in a while. But right now, the configuration of those agents can’t be versioned, reviewed, tested on a branch, or reproduced across projects. Config-as-code is the natural next step – it’s what turns automations from an experiment into a production workflow.

Operating System (if it applies)

Windows 10/11
MacOS
Linux

3

can you elaborate? (I use yml files to automate github actions - more or less - but still haven’t grasped them yet)

4

Sure, Cursor recently added a new automations feature which is really powerful, but is currently configured via the Web UI only. I’d find it really useful to move the Cursor Automation config to a yml file similar to Github actions.