How can we disable manual “Approve workflows to run” for Copilot PRs in an Organization repository?

[ValerieKC]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

Hi everyone,

I’m experiencing an issue with GitHub Actions in an Organization-owned repository, and I’d appreciate clarification on the expected behavior.

---

Setup

• The repository is under an Organization (not a personal account).
• We are using GitHub Copilot to develop features.
• Copilot creates a branch and opens a PR into our development branch.
• We have a workflow configured to trigger on:

on:
  pull_request:
    types: [review_requested]

Intended behavior:

When a PR transitions to Ready for review (i.e., review_requested), the workflow should automatically run our test scripts as part of CI validation.

---

Problem

Instead of running automatically, the workflow displays:

Approve workflows to run

Manual approval is required before the workflow executes, which breaks our intended CI automation.

---

What I have confirmed

• The PR is NOT from a fork (branch is in the same repository).
• The workflow does NOT use environment protection rules.
• The repository belongs to an Organization.
• Organization setting "Require approval for first-time contributors" is enabled.
• I personally have write access as a Contributor.
• Copilot has previously opened and successfully merged PRs in this repository.

However, workflows triggered by Copilot-authored PRs still require manual approval.

---

Questions

1. How can we disable manual "Approve workflows to run" for Copilot-authored PRs in an Organization repository while keeping Organization-level protections enabled?

2. Why is Copilot still considered a first-time contributor even after it has previously opened and merged PRs in this repository?

3. In the same PR, after I manually approve the workflow once and it runs successfully,
   if I later comment and ask Copilot to make changes, Copilot updates the PR, the PR state transitions again to review_requested, and the workflow is triggered —
   why does it require manual approval again?
   Is approval scoped per workflow run rather than per PR?

---

Any clarification on how GitHub evaluates contributor trust and workflow approvals in this scenario would be greatly appreciated.

Thanks!

[Sameer-710]

This is expected behavior from GitHub Actions, not something specific to Copilot.

Copilot PRs are treated like PRs coming from a fork, so GitHub requires someone to click “Approve workflows to run” for security reasons.

There isn’t currently a way to disable this only for Copilot. The only option would be to turn off the approval requirement for all forked PRs at the organization level, but that lowers security for every external contribution.

So for now, manual approval is required by design.

[ValerieKC]

Thanks for the clarification.

That aligns with what I found in the GitHub documentation as well!

[Suyashtiwari-7]

“Require approval for first-time contributors.”

Even though the PR branch is inside the same repository and not from a fork, GitHub evaluates workflow trust based on the actor who authored the PR, not the repository location. PRs created by GitHub Copilot are treated as coming from a separate bot identity, not from you personally.

That’s why:

The workflow shows “Approve workflows to run”

Copilot is still treated as a first-time contributor

Manual approval is required again after new commits

Approval is scoped per workflow run, not per PR. Every time new commits are pushed and the pull_request event triggers again, GitHub evaluates trust again and requires approval.

How to disable manual approval

You have three options:

Option 1 — Disable the organization requirement (global change)
Organization → Settings → Actions → General
Disable “Require approval for first-time contributors”

• This affects all repositories in the organization.

Option 2 — Use pull_request_target instead of pull_request

on:
pull_request_target:
types: [review_requested]

This runs in the context of the base branch and avoids the approval requirement.

• Only use this if your workflow does not execute untrusted PR code directly.

Option 3 — Trigger CI on push instead

on:
push:
branches:
- your-development-branch

This bypasses contributor approval checks entirely.

[Suyashtiwari-7]

hey can u mark it as correct answer as im bulding my github profile i would help me a lot!!

[SIMARSINGHRAYAT]

Practical Recommendation:

The manual approval requirement for Copilot PRs is a security-first design from GitHub, and trying to bypass it completely is not advisable.

Best approach instead:

1. Accept the approval step as part of your CI/CD - It's actually valuable because Copilot-generated code gets human review

2. Optimize the workflow trigger - Use the pull_request_target trigger with paths filter to run only on relevant file changes:

   on:
     pull_request_target:
       types: [opened, synchronize]
       paths:
         - 'src/**'
         - '!docs/**'

3. Fast-track approval process - Designate specific team members to quickly approve Copilot PRs in your CI system (GitHub Apps, branch protection rules with team auto-review)

4. Monitor approval metrics - If approvals are taking too long, it might indicate you need:

   • More reviewers assigned
   • Clearer approval automation rules
   • Different trust levels per team member

Note: GitHub intentionally requires approval for all external contributor PRs (including Copilot) to prevent unauthorized code execution. This protects your repository's integrity!