Cursor agent GIthub issue label change trigger

[Ronnie_Kilsbo]

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Docs list GitHub trigger “Issue label changed” (non-PR issues):

Automations | Cursor Docs

Automations UI (desktop Agents Window AND the web Automations page) only offers PR label triggers — no Issues option / toggle.

"label": {
    "labelName": "...",
    "onAdded": true,
    "onRemoved": false,
    "pullRequests": true,
    "issues": false
}

Prefill with issues: true, pullRequests: false still renders as PR-only. UI cannot configure issue-label triggers even though docs + schema imply support.

Blocks issue-label–driven agent loops (impl / review / QA handoffs on GitHub issues). Hard blocker.

Steps to Reproduce

1. Open Automations (desktop or cursor.com/automations)
2. Create automation → select repo with Cursor GitHub App connected
3. Add Trigger → GitHub → look for issue label / “Issue label changed”
4. Only PR label options appear; no Issues toggle / no issue-label trigger

Expected Behavior

Expected: Issue label changed available as documented (issues: true / non-PR issues) on both web and in Cursor App.

Actual: PR-only label trigger in both UIs (Cursor Automations in Mac App, as well as Web App).

Screenshots / Screen Recordings

Operating System

Other

Version Information

For Cursor Mac App:

Version: 3.12.17
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.4.0

For web, just go to Cursor web app and add automation.

For AI issues: which model did you use?

NA

For AI issues: add Request ID with privacy disabled

NA

Additional Information

I think the intention here is to allow label change on issues, not only PRs, and it’s highly valuable, as it’s working on other harnesses such as Claude Code.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[deanrie]

Hey, thanks for the detailed report. The diagram and screenshots from both UIs really helped.

Confirmed: the docs do list the GitHub trigger Issue label changed for issues, but in the Automations UI on both web and desktop only PR label triggers are currently available, and the Issues toggle doesn’t show up. Prefill with issues: true also renders as PR-only, just like you described. This is on our side, and I’ve reported it internally.

I can’t share an ETA for a fix yet, but I’ll reply in this thread as soon as I have an update.

[tcollett19]

Hi @Colin,

I’d like to add onto this and submit a request to add support for issue-level labels (see below).

Feature request for product/service
– Other –

Describe the request
Following up on this thread (and the note that label-change triggers are rolling out): please ensure GitHub labeled / unlabeled events on issues are first-class Automation triggers—not only pull requests.

Our delivery spine is issue-driven. Labels on issues (e.g. spec-approved, ready-for-finalize, neo:review) are the primary dispatch signal for agent lanes. PR label triggers alone do not cover that model.

Requested Capability (Details): Allow users to create automations that trigger when GitHub emits a labeled or unlabeled event on an issue (in addition to any PR support already shipping). Specifically:

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 spec-approved is applied”) as well as a wildcard/any-label option.

Why This Matters: Labels are the primary dispatch mechanism for teams that use GitHub issues as their orchestration layer. Our workflow applies labels to issues to signal that a specific automated action should run — Spec Kit advance, review fan-out, close-the-loop, finalize prep, triage routing, etc. Without issue-level label triggers, we cannot wire Cursor Automations into our existing operational model even if PR label triggers exist.

Current Workaround and Why It’s Insufficient: The 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
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 issue number, and the actor who applied the label — the same pattern used by other GitHub triggers that pass event context to the agent.

If PR labeled / unlabeled already shipped: please confirm issue labeled / unlabeled are in scope for the same release (or on a near-term roadmap with parity), including the same label-filter UX and event context payload.

GitHub API Reference
These events are standard GitHub webhook payloads:

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 issue-orchestrated use cases until issue-level label triggers exist. We are currently paused on automation rollout pending this feature (or explicit confirmation that issue labeled/unlabeled are already available with label filtering).

[deanrie]

Hey, thanks for the detailed write-up. The context around issue-driven dispatch and why a webhook workaround won’t work makes sense.

This is basically the same problem as in that thread: issue-level label triggers (labeled/unlabeled on GitHub issues) aren’t exposed in the Automations UI right now, even though the backend supports them. So there’s no need for a separate feature request. Your case is covered by the same issue we already reported internally based on Ronnie’s post.

I still can’t share an ETA, but we’re tracking the thread, and I’ll post an update here as soon as we have one. Your UX breakdown (label filter, wildcard, event context with issue number and actor) is helpful. I’ll add it to the report as the expected behavior.

For now, the suggested workaround is still a webhook trigger, and I see why that doesn’t fit your self-hosted setup. I don’t have a better option until a native trigger is available. I’ll let you know when there’s news.

[watsonben (Ben Watson)]

I’m not sure if this is the same issue, or if it needs to be separate — let me know and I can split if needed — but we’re seeing this on the Approval Agents product too.

It looks like even for PRs, it’s not allowing the label to be selected at all.

Adding the label option under triggers gives me this (repo redacted):

There is no option to select which label, or whether it should trigger on that label being added/removed.

I am using Cursor on the web — Chrome Version 150.0.7871.182 (Official Build) (arm64)

We’re on the Team plan, in case that matters.

It doesn’t stop me from using Cursor, but it does stop me from being able to use the Approval Agents.

[deanrie]

Hey, thanks for the report and the screenshot. I see your Approval Agent Pull Request Router and Approver using the Label Change trigger, but there’s no way to pick a specific label or choose added or removed.

This is separate from the original thread. It’s a different product Approval Agents and a different symptom. Ronnie’s issue is that Automations doesn’t have an issue-label trigger like the docs say, while your issue is that the Label Change trigger config is empty and you can’t set the label name or the event. So yeah, let’s split it. Please create a new thread for this case Approval Agents, Label Change with no label selector and no added/removed, attach the same screenshot, and mention you’re on web Chrome 150.0.7871.182 and on the Team plan.

That way we can track it separately and not mix it with the issue-label problem. Send the link to the new thread here and I’ll pick it up.

[watsonben (Ben Watson)]

@deanrie of course! Here is the new topic: Unable to configure triggers in Approver Agents