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.

5

Feature request for product/service

Describe the request

Problem:

Teams maintaining multiple automations across multiple repositories currently must manage instruction prompts exclusively through the Cursor web UI. When instructions are long, complex, or shared across repos (e.g., security remediation playbooks, PR review checklists), this creates several pain points:

  1. No version history – instruction changes cannot be tracked, diffed, or reviewed through PRs
  2. No cross-repo reuse – identical or near-identical instructions must be manually duplicated per repo
  3. Drift – the UI copy and the team’s source-of-truth documentation diverge silently
  4. No programmatic updates – CI/CD cannot update instruction text after a template repo changes
    Proposed solution: Add an Automations Management API and/or a git-sync mechanism for automation definitions. Two complementary approaches:

Option A – API endpoints for automation CRUD:

GET    /v0/automations/{id}         # read definition (instructions, triggers, tools, model)
POST   /v0/automations              # create automation
PATCH  /v0/automations/{id}         # update instructions, triggers, tools, model
DELETE /v0/automations/{id}         # delete automation

This would allow teams to store instruction text in a central git repo and sync it to Cursor via CI (e.g., on merge to main, update all automations that reference changed files).

Option B – File-based automation definitions (declarative):

Allow automations to be defined in a .cursor/automations/ directory in the repo, similar to how .cursor/rules/ works today:

.cursor/automations/security-scan.yaml:

triggers:
  - type: scheduled
    cron: "0 8 * * 1"
  - type: github
    event: ci_completed
model: codex-5.3-high
tools:
  - open_pull_request
  - mcp: github
instructions: |
  You are a security maintenance agent...
  (full prompt text here)

Cursor would read this on each trigger and use it as the automation definition, with the git repo as the source of truth.

What Cursor would need from teams to validate this:

  • Number of automations per org (we run ~10 across 5 repos)
  • Whether instructions are shared/templated across repos (yes, from a central config repo)
  • Average instruction length (ours are 150-220 lines of markdown each)
  • Whether triggers/tools change frequently vs. instructions (instructions change 5x more often)
  • Whether teams use team-owned vs. private automations (team-owned)

Why this matters: As automations become production-critical (security remediation, incident response, CI handlers), they need the same engineering rigor as application code: version control, code review, rollback, and cross-repo consistency.

Screenshot / Screen Recording

SCR-20260416-jllx.png
SCR-20260416-jllx.png6574×2918 1.93 MB

Operating System (if it applies)

MacOS

7

Thank you for your feedback! We’ve explored several approaches to storing automations as code but haven’t yet identified the ideal format. We’re continuing to track requests in this area.

There are two aspects we’re considering: (1) a declarative format for defining automations, and (2) APIs for managing them programmatically.

We’ve added your input to our internal feature requests where we’re tracking this!

1 Like