Feature request for product/service
– Other –
Describe the request
Add support for GitHub labeled and unlabeled events on pull requests and issues as first-class triggers in Cursor Automations. Today, automations can trigger on PR lifecycle events (opened, pushed, merged, commented) and branch pushes, but there is no way to trigger an automation when a label is applied to or removed from a PR or issue. This is a blocking gap for our team.
Requested Capability (Details): Allow users to create automations that trigger when GitHub emits a labeled or unlabeled event on a pull request or issue. Specifically:
PR labeled — When a label is added to a pull request.
PR unlabeled — When a label is removed from a pull request.
Issue labeled — When a label is added to an issue.
Issue unlabeled — When a label is removed from an issue.
Each trigger should support filtering by one or more specific label names (e.g., “trigger only when the label neo:review is applied”) as well as a wildcard/any-label option.
Why This Matters: Labels are the primary dispatch mechanism for teams that use GitHub as their orchestration layer. Our workflow relies on applying labels to PRs and issues to signal that a specific automated action should run — code review, compliance checks, triage routing, deployment gating, etc. Without label-based triggers, we cannot wire Cursor Automations into our existing operational model.
Current Workaround and Why It’s Insufficient: The suggested workaround is to use webhook triggers, which requires us to create and maintain GitHub Actions workflows that POST to the Cursor webhook endpoint. This introduces unnecessary complexity: a separate workflow file per automation, secrets management for the webhook API key, and an open question about whether our self-hosted GitHub Actions runners can reach the Cursor webhook bridge at all. The workaround negates the core value proposition of Cursor Automations, which is to eliminate the need for bespoke GitHub workflow plumbing.
Proposed Trigger UX: Consistent with the existing GitHub trigger pattern in the Automations UI:
Trigger Name Fires When
PR labeled A label is added to a pull request
PR unlabeled A label is removed from a pull request
Issue labeled A label is added to an issue
Issue unlabeled A label is removed from an issue
Each trigger should expose a Label filter field (text input or multi-select) where the user specifies which label name(s) activate the trigger. An empty filter means any label fires the trigger.
The automation prompt should receive context about which label was applied/removed, the PR or issue number, and the actor who applied the label — the same pattern used by other GitHub triggers that pass event context to the agent.
GitHub API Reference
These events are standard GitHub webhook payloads:
pull_request with action: “labeled” or action: “unlabeled”
issues with action: “labeled” or action: “unlabeled”
Both payloads include the label object with name, id, color, and description.
Priority note: This is a blocking request for us! Our team cannot adopt Cursor Automations for our primary use cases until label triggers exist. We are currently paused on automation rollout pending this feature.
