How to auto-approve workflow execution when Copilot coding agent run?

[doggy8088]

Select Topic Area

Question

Copilot Feature Area

General

Body

I am the repository owner and created an issue. I assigned "Copilot" to that issue and triggered the Copilot coding agent to start. However, when the Copilot coding agent runs, I'm always required to approve its workflow execution.

Is there a way to automatically allow workflow execution whenever "I" assign Copilot to an issue?

[rootsom]

Hey, jumping in here because I’ve noticed the same thing while trying out Copilot’s coding agent on a few repos.

Even when the repo owner assigns Copilot to an issue, GitHub still asks for workflow approval. It feels like there should be a way to auto-approve that when the owner initiates it — but I haven’t found any setting that allows it yet.

Is this just a default GitHub security policy for all workflow_dispatch events triggered by Copilot, or is there a permission tweak or repo config that can allow trusted auto-approvals in this case?

Curious if anyone’s figured out a clean workaround 👀

[KnightNiwrem]

It is part of Github's security risk mitigation, as the Github Action workflow doesn't have the same firewall restriction as Github Copilot Agent environment.

Ref: https://docs.github.com/en/copilot/using-github-copilot/coding-agent/about-assigning-tasks-to-copilot#risk-copilot-can-push-code-changes-to-your-repository

Restricts GitHub Actions workflow runs. Workflows are not triggered until Copilot's code is reviewed and a user with write access to the repo clicks the Approve and run workflows button. See Reviewing a pull request created by Copilot.

[ConnorDBurge]

So no way to have it just run it automatically?

[dosaki]

It would be great to define which workflows are safe for Copilot to run automatically, such as workflows that run tests.

[KnightNiwrem]

I'd argue that it's not quite that simple. Because Copilot has the ability to edit files, it can also edit the workflow file itself. Simply defining which workflow type is safe, isn't really safe, if Copilot can modify the internals of that workflow.

One might be tempted to say, we can detect when Copilot modifies the workflow file and deny all. This is true.. to an extent. But workflows also typically call scripts within the repo - e.g. run ./something.sh. This means that Copilot can still modify the internals by modifying something.sh instead of the workflow file, itself.

[dosaki]

That's a fair point 👍

[grepsedawk]

What about which actions+a checksum of their contents?

[riderx]

pretty simple if workflow are touched then approval otherwise not

[castrogusttavo]

Currently, there is no way to bypass the required manual approval for a GitHub Actions workflow triggered by GitHub Copilot or any app/bot account, even if you are the repository owner. This approval step is a security measure designed to prevent unauthorized or unintended workflow executions when triggered by automation or external actors.

The only workaround is to ensure that the workflow is triggered by a trusted actor (like a personal access token associated with your account) or to run the job manually after approval. GitHub does not provide an option to auto-approve these workflows for bots like Copilot.

[RobBiddle]

This definitely limits the usefulness of the Copilot coding agent feature.

The advantage of this feature would come from being able to avoid the constant copy/paste cycle of moving workflow outputs from GitHub into the IDE and instead be able to work on other things while Copilot re-runs workflows on its own while iterating through fixing errors and attempting to achieve goals, which is exactly why I just went through the trouble of setting it up and trying the feature.

Right now, using Copilot coding agent is slower as a complete development process compared to using VS Code Agent Mode locally.
It seems like all it does is trade the copy/paste process for a continual process of clicking buttons to approve workflows and then adding a

"@copilot keep working on this."

comment. 🫤

If the concern really is that the Copilot coding agent could modify Workflow files, couldn't it be a requirement/default that the .github/workflows/ path use a CODEOWNERS file that prohibits Copilot from doing that?

To go a step further, the Copilot coding agent could require a specific version of the official actions/checkout which could be made so that files outside .github/workflows/ are not executable.

[KnightNiwrem]

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

On "just use CODEOWNERS" for a specific folder

[RobBiddle]

Surely GitHub can figure out a way to prevent Copilot from being allowed to modify CODEOWNERS or anything else that is a concern.

[KnightNiwrem]

It's not that they can't figure that out. It's that the "relevant files" potentially is the entire project.

For example, imagine I have a workflow that perform e2e tests. This means all parts of the application code needs to run in some ways at least - assuming we are going for 100% test coverage.

This means that literally any part of the application code could be a potential vector for attack - e.g. coding agent injects some kind of eval or fetch call to exfiltrate sensitive data out, in some part of the application code.

[shen-sat]

It's not that they can't figure that out. It's that the "relevant files" potentially is the entire project.

Agree with @KnightNiwrem - this is the security risk in a nutshell. If a runner can edit a file, and that file executes as part of the build, then that's immediately a security risk.

To offer an alternative: if we zoom in on the security risk, what Im essentially worried about is the agent writing some malicious code that sends data somewhere unwanted (for example, the agent writes code that sends secrets to malicious-website.com). If this is in fact the only security risk, then a solution could be to add a whitelist of urls to the build - and effectively block requests to malicious websites

This way I could be confident to let the build run any code in the build (even malicious code) - because the whitelist prevents a "wall" that the agent can never bypass

[nunoatgithub]

You can create a fine grained personal access token for that repo, with permissions Actions: write, and then extend the capabilities of the github mcp server used by the agent in that repo by telling it to use this token, instead of the more limited GITHUB_TOKEN, as described here

https://docs.github.com/en/enterprise-cloud@latest/copilot/how-tos/use-copilot-agents/coding-agent/extend-coding-agent-with-mcp#customizing-the-built-in-github-mcp-server

Tested and working.

PS: to find out that actions:write was the needed permission, this part of the docs was key :
"To help you choose the correct permissions, you will receive the X-Accepted-GitHub-Permissions header in the REST API response. The header will tell you what permissions are required in order to access the endpoint."

See https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28

Also, as a side note, I did not have to add any permission definitions to the workflow yml itself, for this to work.

[stevoland]

Hi, for clarity, are you saying that just by setting COPILOT_MCP_GITHUB_PERSONAL_ACCESS_TOKEN secret to a token with actions:write - workflows run automatically on copilot's commits?

This is surprising to me - I thought the mcp was readonly and the agent harness git actions were completely separate. Is there anything more to it? I would love for this to be possible.

Thanks for your time

[nunoatgithub]

Not on commits, this allows the agent to trigger jobs manually without approval from you, like you do yourself when you trigger a job, which you can instruct it to do as part of a CI health task (for example). This will be logged as made by you (it's your token) in the job history, but from the copilot's branch. Pay special attention to this part of the docs in that link

// Remove "/readonly" to enable wider access to all tools.

[KnightNiwrem]

From what I understand, the workaround is basically telling the GH Copilot Agent to use your PAT to essentially "click" on the approve workflows to run button, except via API, and by assuming the user's identity via their PAT.

Basically, GH Copilot Agent commits are prevented from triggering workflow for security reasons as usual, but GH cannot (have not?) prevented the flow where agents perform the same kinds of API calls as a human normally would.

[stevoland]

Ahh, that makes sense now. Thanks both.

As an aside, I've seen this in the marketing:

We’re also providing:

New branch controls that give you granular oversight over when to run CI and other checks for agent-created code.
Identity features to control which agent is building the task, managing access, and policies just like you would with any other developer on your team.
One-click merge conflict resolution, improved file navigation, and better code commenting capabilities.

https://github.blog/news-insights/company-news/welcome-home-agents/

But can't find any details anywhere

[guettli]

Are there better alternatives than Copilot Agent? I mean tools which can create PRs which trigger a CI run. I am willing to switch to an alternative (GitLab) , if required.

[al-beton]

Devin.ai

[riderx]

I will use webhook to auto approve when it's ready and made by copilot again something stupidly done ...

[theophanemayaud]

I think the situation should really be improved. Codex, cursor, claude, theta ll simply create PRs that automatically trigger workflows.
I actually like the safety built in with the copilot setup, and the copilot environment setup is amazing, much better than theirs.
I think what could work, is to add a repository configuration option to «auto approve workflows runs if copilot hasn’t modified the workflows». I know my workflows, I know their dependencies, and I know they have no way of doing something unexpected unless they’re specifically modified.

I would even prefer just having a full «auto approve workflows» setting per repo, as the productivity/risk tradeoff on a private repo with only approved contributors being able to push, is very much in favor of auto running workflows.

Please fix !!!

[vincentaudoire]

Not a great workaround but you could use a Copilot agent hooks and trigger the CI after the sessionEnd has fired.

This workaround is working for me, obviously not great and hopefully temporary.

[billie355]

you done???

[eguiraud-pf]

What we ended up using is a custom JavaScript action to copilot-setup-setps.yaml that has a post step that approves the PR.

[hyunfei01]

You can use an agent hook to send a repository dispatch event. That event can tell a downstream workflow which PR the agent is working on. Then you can create a separate GitHub Actions workflow to receive that event and automatically approve the PR or perform other follow-up actions.

It is better to use a sessionEnd hook for this. I spent quite a while blocked because I was using an agentStop hook, which the coding agent does not seem to support yet.

[Vilsepi]

I don't know how new this setting is, but under the Project Settings -> Copilot -> Coding agent, there is now a toggle switch:

Require approval for workflow runs: When Copilot pushes changes, require approval from a maintainer with write access before Actions workflows are run. Allowing GitHub Actions workflows to run without approval may allow unreviewed code written by Copilot to gain write access to your repository or access your GitHub Actions secrets.

The recommended value is On obviously, but you can disable this to autorun the workflows for the Copilot. I'm not really worried of Copilot itself, but I'm wondering is it possible that an outsider opens a PR to my repo, and somehow manages to trigger Copilot. If I understand correctly, you can add a new workflow in a PR that can do pretty much anything, and I'm wondering could that workflow be triggered via Copilot.

[theophanemayaud]

Nice, finally !!! Turning it on, on, on !!!

[shen-sat]

Would be interested to know what you think of the security risk as outlined here - because it's a risk that comes from the agent itself, not an external threat (eg an outsider opening a PR)

Im particularly interested to know if you've found a way to mitigate the security risk - it's the only blocker that I imagine prevents many orgs from switching on auto-approve

[Vilsepi]

Yeah, I agree that the main risk is that the agent researches the Internet and comes up with a bad idea, and writes a workflow or code that uploads the repo secrets to a remote server. It could be a GitHub Actions workflow, a 3rd-party workflow plugin, a shell script called in a workflow, or application code under test.

I also agree that the only viable solution is would be an allowlist of external addresses that the workflow may call.

[monperrus]

Confirming, one can set "Require approval for workflow runs" to "Off". Thanks Github.

[armorer-labs]

The approval step makes sense to me when framed as an authority boundary, not just a workflow convenience toggle. The real question is not only who assigned Copilot, but whether unreviewed agent-authored changes have crossed into a domain where they can now trigger secrets, deployments, writes, or other high-trust actions.\n\nSo the interesting product direction would be more granular execution protections rather than a simple global on/off:\n- which workflows can auto-run\n- under what path or file-change conditions\n- whether workflow files themselves changed\n- whether the run can reach secrets, environments, or external side effects\n\nThat kind of policy keeps the boundary legible instead of treating all agent-triggered workflow execution as equally safe or equally dangerous.

[ghostinhershell]

Hi @doggy8088 and @KnightNiwrem 👋🏾

Because of a new ship back in March, @Vilsepi's answer here is the most up to date and correct answer. I've unmarked the current marked answer and marked this response as the answer to this discussion so that users searching for a solution will have access to the most up to date information.

Thank you so much for lending your expertise and helping folks in the Community @KnightNiwrem & @Vilsepi! 🚀