Doubled workflow runs/checks when using Copilot Agent mode?

[rkohanyi]

Select Topic Area

Question

Copilot Feature Area

Copilot Agent Mode

Body

Hey, I've recently started experimenting with Copilot Agent mode and I noticed a quirk? Bug? Not sure.

I created a repo to demonstrate it, here's the steps I took

• created new empty repo
• commited an README
• created an issue where I described I need a hello world Java app
• assigned this to copilot, which did its job
• then I created another issue to ask it to create workflows for PRs and release on main, which again it did very well

Here is my question, why does the workflow on the PR is triggered twice? What do I do wrong? Workflow seems fine (maybe I'm obtuse or something).

Here you can you see that the PR has 2 checks instead of 1.

Why?

My (un?)educated guess is due to how Copilit works, creating synthetic commits or whatnot behind the scenes, but it is still weird.

Any idea? Thanks a bunch!

[khizarbakhtiar1]

Based on your question, this seems to be about GitHub Copilot's behavior on GitHub.com (specifically Copilot Workspace or GitHub Issues integration), rather than VS Code's Copilot Agent Mode feature.

However, if you're asking about Copilot Agent Mode in VS Code, here's how to enable it:

Use the chat.agent.enabled setting to enable agent mode for chat in VS Code. When enabled, agent mode can be activated via the dropdown in the chat view.

Regarding your workflow question: The issue you're describing about duplicate workflow runs appears to be related to GitHub Actions configuration, not VS Code settings. This typically happens when:

1. The workflow is triggered by both push and pull_request events on the same branch
2. The workflow file exists in both the base and head branch of the PR

To troubleshoot GitHub Actions workflows, you would need to review your workflow configuration in your repository. This is outside the scope of VS Code configuration.

If you need help with Git operations in VS Code, you can use the Git: Pull command to sync your repository.

[barb4rian]

Select Topic Area

Question

Copilot Feature Area

Copilot Agent Mode

Body

Hey, I've recently started experimenting with Copilot Agent mode and I noticed a quirk? Bug? Not sure.

I created a repo to demonstrate it, here's the steps I took

• created new empty repo
• commited an README
• created an issue where I described I need a hello world Java app
• assigned this to copilot, which did its job
• then I created another issue to ask it to create workflows for PRs and release on main, which again it did very well

Here is my question, why does the workflow on the PR is triggered twice? What do I do wrong? Workflow seems fine (maybe I'm obtuse or something).

Here you can you see that the PR has 2 checks instead of 1.

Why?

My (un?)educated guess is due to how Copilit works, creating synthetic commits or whatnot behind the scenes, but it is still weird.

Any idea? Thanks a bunch!

This behavior isn’t necessarily a bug — it’s likely due to how Copilot Agent Mode interacts with your repository and triggers GitHub Actions events.

When Copilot creates or updates a pull request, it often performs operations like:

creating synthetic commits under its agent account, and

pushing updates or metadata to the PR branch.

Each of those pushes can independently trigger your workflow if it’s configured with:

on:
pull_request:
types: [opened, synchronize, reopened]

or even just:

on: [pull_request]

✅ How to fix it:
Limit your triggers so they only run once per meaningful PR change, for example:

on:
pull_request:
types: [opened, reopened, ready_for_review]

Or, if you want even finer control:

if: github.actor != 'github-copilot'

(This skips jobs triggered by Copilot’s internal commits.)

So yes — your hunch is correct. It’s not that you did something wrong; Copilot likely pushes more than once when it sets things up.
Hopefully, GitHub will refine this behavior so the agent’s synthetic pushes don’t double-trigger workflows.

[grahame-student]

Not sure that's the only reason though. Looking at the duplicate runs I can see that they are for the same git sha and the exact same events!

If the sha's were different then sure, that's a sequence of commits each of which triggers a run.

[rkohanyi]

Well, I'll look into it. The problem seems to be that the doubled runs are exactly the same. So I can't skip one or the other based on conditions.

I must say tho', the answers here seem really Copilot-ish 😅 and I did ask it to fix it, it suggested such fixes, but never actually was able to fix the problem.

[rkohanyi]

Well, I'll look into it. The problem seems to be that the doubled runs are exactly the same. So I can't skip one or the other based on conditions.

I must say tho', the answers here seem really Copilot-ish 😅 and I did ask it to fix it, it suggested such fixes, but never actually was able to fix the problem.

I have echoed the GitHub object from run (in another private repository where I am experiencing this problem too) and the two are completely the same except run_id, run_number and some other fields containing generated IDs.

So based on such logic this doesn't seem skippable.

Just an idea, but run number X could be skipped if run number X + 1 exists, which is kind of hacky.

[grahame-student]

I'm seeing the same unexpected behaviour, GitHub coding agent changes regularly trigger duplicate runs. I've been seeing this behaviour using the coding agent from the GitHub website, not via a separate IDE.

I've tried tuning the concurrency configuration with little success.

The impact that I'm seeing is that when a PR is targeting a protected branch and the duplicate workflows gate merging the changes in the PR the required status checks get easily confused causing a deadlock that requires a change from a human to get past! I could live with the noise of the redundant runs, but clashing with the status checks is the big pain point. It's especially painful when the workflows can't easily be cancelled, e.g. building a container doesn't seem to respect requests to cancel, admittedly that's a different issue that compounds with the duplicate runs.

[rkohanyi]

FYI @grahame-student I'm discussing this GitHub Support case in the meantime. Will post an update once it's settled. The first back and forth yielded no result. Copilot makes separate commits like a human would, doing atomic changes. But the two workflow runs which are triggered are for the same commit hash. If you could inspect that (when the code is checked out) it would be helpful.

I'm not exactly sure who the checkout action works (does it checks out the latest ref available or the ref that triggered the run - this latter would be the expected from my side).

[grahame-student]

@rkohanyi

Attached are the full logs from a workflow and its duplicate. they relate to grahame-student/gnu-tools-for-stm32, a public repo I've been using as a testbed for copilot.

run_394.txt
run_395.txt

• When I make a change to a branch I see 1 run triggered for each workflow.
• When copilot makes a change to the same branch I see 2 runs triggered for each workflow.

[rkohanyi]

Seeing the exact same. No progress on the GitHub support ticket on my behalf. Workaround is just to ignore it :)

[rkohanyi]

Quick Fix

For anyone who's following this. Add this (or something akin to this) to your workflow file:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number }}-${{ github.event.pull_request.head.sha }}
  cancel-in-progress: true

Working example here.

Important

Using Copilot with such a workflow still results in two workflow runs being generated, but the "earlier" will be cancelled immediately.

See evidence here:

• Sample PR
• Runs triggered by Copilot change:
  • Run #7 ➡️ cancelled automatically
  • Run #8

Reason

Whether this is a bug or a feature, who knows, it happens because (as per my understanding at the moment), Copilot commits two things too fast, not like human's would do and this triggers two workflow runs. Adding concurrency control is a sanity check that iff the same exact commit triggers two runs the former of those will be cancelled. Which is not the best solution, but it works.