Cursor Automation: Push-to-Main Runs Are Being Cancelled by New Runs Instead of Running Concurrently

[Rahel_Arabella]

Hi team,

I’m using a Cursor Automation with the trigger set to “Push to main” on my repository.

My use case is that every push to the main branch should trigger a code scan, and I expect all runs to execute independently. Running multiple scans concurrently is completely acceptable and actually required for my workflow.

Previously, this worked as expected. If multiple pushes happened around the same time, Cursor would start multiple automation runs and all of them would complete successfully.

However, since around June 18, 2026 (Indonesia time / UTC+7), the behavior seems to have changed.

What happened before

• Push #1 → Automation starts
• Push #2 → Automation starts
• Push #3 → Automation starts
• All runs execute and complete successfully, even if they overlap in time

Current behavior

When multiple pushes happen close together:

• The newest run starts normally
• Previous runs are automatically cancelled
• The cancelled run shows:

Cancelled by newer run

And the details say:

This run was cancelled because a newer event arrived for the same target (push, PR update, or CI completion). The newer run is handling the latest state.

What I need

I do not want newer pushes to cancel older runs.

My goal is:

• Every push event should create its own automation run
• All runs should be allowed to execute concurrently
• No automatic cancellation when a newer push arrives
• Each push should perform its own code scan, regardless of whether another run is already in progress

Question

Has there been a recent change to automation concurrency or cancellation behavior?

Is there any setting, configuration, or recommended approach that allows all push-triggered automation runs to execute independently without being cancelled by newer runs?

I would like the behavior to be the same as before, where concurrent push-triggered runs were all allowed to complete successfully.

Thanks!

[Tom_Coustols]

hey @Rahel_Arabella, there was just an issue cursor side that affected all automation, could this be linked with the issue you just had? https://status.cursor.com/

check today incident

[Rahel_Arabella]

Hi, I already reviewed that, but didn’t see any detailed information related to my problem. Also this automation concurrency or cancellation behavior have been occuring since Friday, 18 June (Indonesia time / UTC +7)

[hansgo (Hans)]

Can you make this a feature an automation can opt-out of? This is breaking our existing automations

[deanrie]

Hey, thanks for the detailed report and the screenshots, they show the difference really well. On the Jun 8 screenshot you can see three parallel runs, and they all finished as Succeeded. On Jun 22, one of the two runs from the same push is marked Failed with “Cancelled by newer run”. This isn’t related to the incident on status.cursor.com that was mentioned above.

This behavior did change on purpose. Supersession now applies, when a new event comes in for the same target, any still running run for that target gets canceled. For the “Push to main” trigger, the target is the branch, so a new push to main cancels the previous unfinished run. This is to avoid spending runs on outdated commits when the branch has moved forward.

The downside is there isn’t a setting right now to turn this off and allow all push triggers to run in parallel. Per-automation concurrency or queue controls are on our roadmap, but I can’t share an ETA yet.

@hansgo same thing for your case, I’ve logged your opt-out request too.

If this breaks a critical workflow, can you share a bit more detail about your scenario, like how many pushes happen in what time window, and what the scan does. That’ll help us prioritize.

[Rahel_Arabella]

Thanks for the explanation! That helps clarify why we’re seeing this behavior.

Unfortunately, this change has a pretty significant impact on our workflow because we’re using Cursor Automations as part of our production scanning pipeline.

Here’s a bit more context about our use case:

• Every GitHub push should immediately trigger its own automation run.
• Each automation performs a code scan.
• Once the scan is complete, the results are uploaded to Google Drive and the corresponding Jira ticket is updated automatically.
• Every push represents an independent request, so even if multiple pushes happen at the same time, they all need to be processed.

The first issue we encountered was the one regarding environment variables not being available for GitHub-triggered automations.

Because of that, once an automation finished, it could no longer upload the scan results to Google Drive or update Jira, since the required credentials were stored in environment variables.

To work around this, we changed our architecture:

• The automation only performs the scan.
• A separate script runs every 5 minutes and polls GitHub for completed automation results.
• That script then uploads the results to Google Drive and updates Jira.

Although this wasn’t ideal, it was still manageable because the automations themselves could still run concurrently. The only downside was that result processing was delayed by a few minutes.

However, after the concurrency behavior changed around June 18, we ran into a second issue.

Now, when multiple pushes happen close together, newer pushes cancel the previous automation runs instead of allowing them to execute in parallel.

This is much harder for us to work around.

Our automation traffic is very bursty. Some days or hours have multiple pushes arriving almost simultaneously, and each scan takes around 10–15 minutes.

Previously:

• Three simultaneous pushes would start three scans immediately.
• All three would finish in roughly 10–15 minutes.

Now:

• We have to implement our own queue to avoid losing requests.
• Three simultaneous pushes can now take around 30–45 minutes before all scans are completed.

As traffic increases, the delay grows even more.

So we’re now working around two separate platform limitations:

1. GitHub-triggered automations cannot access the required environment variables, so we had to build an external polling mechanism to process scan results.
2. Concurrent push-triggered automations are now cancelled by newer runs, so we also have to build our own queuing system.

Together, these changes make Cursor Automations much less suitable for our workflow than before.

We’re currently evaluating more robust alternatives because our workflow depends on three things:

• every GitHub push being processed,
• concurrent execution,
• and reliable post-processing after each scan.

If there’s any upcoming support for disabling run supersession or allowing concurrent executions for push-triggered automations, we’d be very interested in trying it.

Thanks again for taking the time to explain the current behavior.

[deanrie]

Thanks for the detailed breakdown of the use case. That’s exactly the level of detail that helps with prioritization. The situation is clear: bursty traffic, 10 to 15 minutes per scan, and supersession turns three parallel scans into a 30 to 45 minute queue. That’s a real hit for a production pipeline.

A couple points separately:

1. Supersession and concurrency. I’ve logged your request to disable supersession and allow concurrent execution for push triggers, along with your scenario. Per-automation concurrency and queue controls are on the roadmap. There’s no opt-out today.

2. Env vars for GitHub-triggered automations. The fact that credentials aren’t available inside an automation started by a GitHub trigger, while they are available for manual or API runs, is a known bug on our side and is tracked separately. No ETA yet, but this is a bug, not intended behavior.

I get that together these two limits push you toward alternatives right now. If there’s an update on either point, I’ll reply in this thread.