Checks completed skips Cursor-agent PRs → forced long cloud-agent polls

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

GitHub “Checks completed” automations do not fire for PRs created/pushed by the Cursor cloud agent (app/cursor / cursor[bot]), even with:

  • Checks completed
  • On Any Completion
  • On PRs
  • by Anyone

CI finishes on the PR, but the automation never starts and Run History stays empty.

This was acknowledged by Cursor staff as a known internal bug on 18 Jun 2026:

@deanrie said Checks completed silently skips PRs created/pushed by the Cursor agent, it was tracked internally, no ETA. That thread has had no update since, and the bug still exists on 7 Aug 2026, and that thread is also closed for additional comments.

Because of this we must use Pull request opened + Pull request pushed and keep a cloud agent polling until checks finish, which burns long agent runs that Checks completed should make unnecessary.

Steps to Reproduce

  1. Create a Cursor Automation on an org GitHub repo with trigger: Checks completed, On Any Completion, On PRs, by Anyone.
  2. Have a Cursor cloud agent open a PR (author app/cursor).
  3. Wait until GitHub Actions/checks on that PR complete.
  4. Open the automation Run History — no run is created.

Control: a human push on an agent-opened PR can make Checks completed fire; agent-only check completions still do not.

Expected Behavior

On any check completion for that PR, the automation should start and appear in Run History, including when the PR was opened/pushed by cursor[bot].

Operating System

Other

Version Information

Cursor web / Cloud Agents & Automations (cursor.com), not the desktop IDE.

Automation: predykt-agents/platform-backend-pr
Repo: Predyktable/predykt (private org)

Example agent-authored PR (CI green, Checks completed never woke):
https://github.com/Predyktable/predykt/pull/127
Author: app/cursor
Opened: 2026-08-07T14:37:29Z
Checks finished ~2026-08-07T14:41Z UTC — automation Run History empty

Related agent PR:
https://github.com/Predyktable/predykt/pull/131

Happy to add the automation UUID if useful.

For AI issues: which model did you use?

N/A

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Prior Cursor staff acknowledgment (18 Jun 2026): Checks completed silently skips PRs created/pushed by the Cursor agent (cursor[bot]); said to be tracked internally, no ETA:

No public update since. Bug still present on 7 Aug 2026.

Workaround we are forced into: Pull request opened + Pull request pushed, then a cloud agent polls until checks finish — long paid runs that Checks completed should avoid.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report and for linking it to the previous thread 163539. It’s the same issue, and it’s still on our radar. I can’t share an ETA yet, but I’ll post an update here when I have one.

You did everything right on the diagnostics side. The control test with a human push matches what we’re seeing. Check completion events for PRs opened or pushed by the agent cursor[bot] aren’t reaching trigger matching, so Run History stays empty. This isn’t anything in your config.

Until we have a fix, besides your polling workaround, there’s one option that sometimes bypasses this issue. It’s not guaranteed and depends on how your CI is set up. Try using the Workflow run completed trigger instead of Checks completed. It listens to a different event type and in some cases doesn’t get filtered out. One important detail is that it usually only fires if the GitHub workflow itself runs on on: push, and the workflow name in the filter is case sensitive. If your workflows run on pull_request, this won’t help.

No need to add the Automation UUID. We have enough details already PR #127, automation predykt-agents/platform-backend-pr. If you try Workflow run completed, let me know if it works.

6

He Dean, thank you for your reply.

I’ll ticket this up and pick it up next week to see if it works, would indeed be a much better workaround. I’ll report back here.

Cheers

7

Sounds great. Let me know if Workflow run completed works. If your CI runs on on: push, there’s a good chance it will. If it runs on pull_request, it unfortunately won’t help, and you’ll need to stick with your polling workaround.

For the main issue, there’s no ETA yet, but it’s on our radar, and I’ll post here as soon as there’s an update.

8

Hi again Dean,

Well, I realised that this would work, had we had one Github actions workflow only, triggered on opened PRs.

But we have several, which would mean that the agent picking up after Github actions workflows would be triggered more than once, and we would have to rely on agents working out when all workflows are done.

This is a bit too stochastic for our use case we think, and too heavy of a workaround, and a bit of a waste of cloud capacity as well I’m thinking.

Cheers.

11

Got it, thanks for checking. I agree, with multiple GitHub Actions workflows, the “Workflow run completed” trigger turns into a guessing game of whether everything has finished. That’s too heavy and unreliable as a workaround for your pipeline. Not the right trade-off.

On the main issue, status is the same. It’s on our radar, but I can’t share an ETA yet. I’ll post in this thread as soon as I have an update. For now, you’ll unfortunately need to stick with the polling option.

12

Super, appreciate it, will monitor here.

Cheers.