Avoid "workflows awaiting approval" when copilot agent create PRs

[ajthinking]

Select Topic Area

Question

Copilot Feature Area

Copilot Agent Mode

Body

When creating an issue and assigning github copilot, it is not allowed to run the actions (tests etc).
So for each iteration I need to press "approve" which slows down the flow quite a bit.

My settings: settings/actions/Approval for running fork pull request workflows from contributors is set to:
"Require approval for first-time contributors
Only users who have never had a commit or pull request merged into this repository will require approval to run workflows."

So, I made a first PR with copilot. Merged it.
Made a second. Still, it needs my approval.

Question: where is the setting to allow copilot to run actions without me babysitting it?

[neeraj2019041078]

Hello Aj ,

To allow Copilot PRs to run actions without manual approval, you can:

Go to Settings → Actions → General

Under “Fork pull request workflows”, set to:

🔓 “Require approval for all outside collaborators” → Off

Or enable “Run workflows from fork pull requests without approval” (not always recommended for security)

Alternatively, convert Copilot-generated PRs into PRs from a trusted internal branch (instead of a fork), where workflows run normally.

[ajthinking]

Would love a non LLM answer, the above replies makes no sense

[KnightNiwrem]

https://github.com/orgs/community/discussions/162826#discussioncomment-13535323

[MuhammadTanveerAbbas]

GitHub treats Copilot PRs as coming from an untrusted fork every time, so it always needs manual approval. There's no setting to bypass that. Even after merging one, it won’t remember it. Only fix is to stop using Copilot's forked PRs and push changes from a trusted branch instead.

[AmanRai8]

GitHub Copilot’s workflow runs are treated as first-time contributors, so approval is needed each time. There’s no current setting to auto-approve its actions—only way is to relax fork workflow approval or keep approving manually.

[OndrejSpanel]

I find current requirement of allowing Copilot Agent running workflows explicitly on each run alibistic and annoying. When it wants to run a workflow, I am not shown any information to help me decide, only an information Copilot wants to run some workflows.

I suggest either allowing me to pre-aprove workflows, or if not, then show me more information, so that I can make a qualified decision. At this moment, I just blindly press Allow, because I have no idea what workflows could it be running and I consider my workflows harmless in general anyway.

[KnightNiwrem]

Why are you running workflows on the initial commit of the PR at all? You should wait for @copilot to finish work before reviewing the PR and running the workflow.

There is not any requirement to run the workflow on every PR commit.

And yes, it's to prevent the agent from making some unsafe changes to your workflow. You should treat every run as if a complete stranger is contributing to your project or PR.

[OndrejSpanel]

I think this is whole a misunderstanding on my side on how workflows interact with Copilot and what purpose they serve. I got confused by the fact copilot is running in action-like environment and assumed it runs those workflows to somehow perform its work. Now I understand they are just my normal workflows running on normal repo events like branch or PR push.

Why this presents a security risk: I think contrary to Copilot agent session, when running workflows there are no firewall rules active and one should make sure the workflows or files used by them are not changed in an unexpected way.

What would definitely help me to understand this better (and to make my decision easier) would be if I was shown what workflows does copilot want to run, instead of just their total number.

Also the documentation might perhaps be cleared, but may it is just my reading skills?

[KnightNiwrem]

I think this is whole a misunderstanding on my side on how workflows interact with Copilot and what purpose they serve. I got confused by the fact copilot is running in action-like environment and assumed it runs those workflows to somehow perform its work. Now I understand they are just my normal workflows running on normal repo events like branch or PR push.

Why this presents a security risk: I think contrary to Copilot agent session, when running workflows there are no firewall rules active and one should make sure the workflows or files used by them are not changed in an unexpected way.

What would definitely help me to understand this better (and to make my decision easier) would be if I was shown what workflows does copilot want to run, instead of just their total number.

Also the documentation might perhaps be cleared, but may it is just my reading skills?

Yes, this understanding is much closer to correct. The only point left is this: copilot does not want to run any workflows. It's your workflow rules that wants to run workflows as a result of a merge request (commit). It's the exact same behavior if anybody else created a pull request to your repo.

[OndrejSpanel]

Thanks, that is indeed more correct. I would however like this point to come across: I want to be shown which workflows am I allowing to run, before I do so. Maybe this is the same with outside contributors - as I never had one, I have no experience with that.

[KnightNiwrem]

Thanks, that is indeed more correct. I would hover like this point to come across: I want to be shown which workflows am I allowing to run, before I do so. Maybe this is the same with outside contributors - as I never had one, I have no experience with that.

Yes, it is the same behavior with outside contributors. It's a behavior that has existed years before copilot existed.

Thus far, it has been a non-issue, as the repo owner should already be well aware of what workflows they have setup themselves in .github/workflows, and they should review the file changes for any unexpected behavioral changes to the workflows.

You could try to argue for a UI improvement, which would be fair. But in practice, you cannot run away from the fact that you have to review the files changes line by line for unexpected workflow changes.

It is entirely possible for workflow behavior to change without a workflow name change. Relying on the summary would be a mistake.

And trying to squeeze potentially hundreds of line changes that may potentially change workflow behavior in the conversations tab, is also a mistake.

[Qasimraza110]

It sounds like this might be related to how GitHub treats Copilot Agent Mode in relation to workflow permissions. Even after merging the first PR, Copilot may still be considered an external contributor in the context of Actions security, which is why it keeps requiring approval.

From my experience, there isn’t currently a dedicated setting to whitelist Copilot so it can run Actions without manual approval. The “Require approval for first-time contributors” rule only applies to human accounts, and Copilot seems to bypass that classification.

If possible, it would be great to have an option in repository settings to explicitly trust Copilot as a contributor so its PRs can run workflows automatically — this would save a lot of manual approvals during iterative work.

[KnightNiwrem]

To be fair, you don't need such an option to exist, if one simply wanted workflows to run without approval.

The solution is simple. Just merge the PR and let the push/commit trigger activate the workflow.

The only difference is whether you comment on copilot's PR on a failing manual workflow, or you create a new issue referencing that the previous PR fails the automatic workflow after merge.

[Qasimraza110]

Ok

…

On Mon, Aug 11, 2025, 4:16 PM KnightNiwrem ***@***.***> wrote: To be fair, you don't need such an option to exist, if one simply wanted workflows to run without approval. The solution is simple. Just merge the PR and let the push/commit trigger activate the workflow. The only difference is whether you comment on copilot's PR on a failing manual workflow, or you create a new issue referencing that the previous PR fails the automatic workflow after merge. — Reply to this email directly, view it on GitHub <#167493 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKUAKAULXT4GCVZWYFCWOZT3NB3Q3AVCNFSM6AAAAACCLESW62VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMBXGA2TINI> . You are receiving this because you commented.Message ID: ***@***.***>

[ThePlenkov]

Hi! What is the workaround? it's very annoying that Copilot cannot bypasss it and what is interesting claude works without this check =)