Pull requests created using this action suddenly requires approval for running workflows?

[dozer75]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Today, we discovered that PR's that are either modified or created automatically by other workflow runs suddenly requires approvals to run workflows that is triggered by pull requests (at least on opened or synchronize). In the PR we get the following

Clicking the link sends us to Approving workflow runs from forks, but this is not any PR based on a fork, but a branch in the repository.

In the workflow itself we also get the possibility to approve, and there I can get a popup that looks like this

The step that created the PR that is related to this uses the peter-evans/create-pull-request action like this

jobs:
  create-pull-request:
    runs-on: ubuntu-latest
    name: 🔄 Create pull request to main
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v6
        with:
          ref: main
      - name: Reset merge branch
        run: |
          git fetch origin ${{ github.ref }}:${{ github.ref }}
          git reset --hard ${{ github.ref }}
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v8
        with:
          branch: release-fix-to-main
          title: Merge release into main
          assignees: ${{ github.actor }}

I found the following documentation Triggering a workflow from a workflow which states that this is expected, but (at least last week) we didn't need to do this approval?

While the documentation is quite clear, we haven't had this issue before today (and last time we used this functionality was a week ago without any approval like this), so we wonder when this was activated? So, if anyone can shed light on this it would be nice.

[ZitouniNidhal]

@dozer75 – I ran into this exact same behaviour recently. The key point is that GitHub’s approval rules are based on the actor who triggers the event, not solely on whether the branch lives in the main repository.

Even though your PR branch is in the same repo, the automated creation/update is likely performed by the github-actions[bot] (or a PAT belonging to a user that GitHub considers a "first‑time contributor"). That triggers the fork/workflow approval policies.

Here’s how to diagnose and fix it:

---

1. Check who opened the PR

Look at the top of the PR page – who is listed as the author?
If it says github-actions[bot] or a bot account, that is almost certainly the trigger. GitHub treats this account as an external/untrusted actor unless it has a history of commits in your repo.

---

2. Review your repository’s workflow approval settings

Go to Settings > Actions > General and scroll to the “Fork pull request workflows” section.

You’ll see two options:

• Require approval for first‑time contributors who are new to GitHub
• Require approval for workflows from external contributors

If either of these is enabled, and the PR author is github-actions[bot] (or a user who hasn’t contributed to this repo before), GitHub will demand approval – even for branches in the same repository.

Quick test: Temporarily disable both checkboxes. If the approval banner disappears, you’ve found the cause.

---

3. Switch to using a Personal Access Token (PAT) with write permissions

Instead of relying on the default GITHUB_TOKEN (which acts as github-actions[bot]), update your workflow that creates/updates the PR to use a PAT from a user with write (or admin) access to the repository.

Example snippet from your create-pull-request step:

- name: Create Pull Request
  uses: peter-evans/create-pull-request@v6
  with:
    token: ${{ secrets.MY_PAT }}   # Use a PAT, not GITHUB_TOKEN
    # ... other options

Once the PR author is a known, trusted user with write permissions, GitHub will no longer flag the workflow as needing approval.

---

4. Double‑check if your repository is a fork

If this repository itself is a fork of another upstream repo, then any PR opened from this fork toward the upstream will always be treated as a fork PR – and approval rules will apply by default. In that case, you’ll need to either adjust the fork settings on the upstream repo, or accept that manual approval is required.

---

5. Immediate workaround

If you need to unblock the PR right now, go to the “Actions” tab on the PR. You should see a button that says “Approve” – click it (you’ll need write permissions on the repo). The workflow will then run.

---

[dozer75]

Thanks for reply,

Here is some answers for your list:

1. As I mentioned, yes these are opened (or modified) by bots, and yes this is the issue, the question is how this suddenly start to happen now because this wasn't so last week for our repos.
2. We don't use (and none of these PR's uses forks as we're not allow forking), but anyway I checked the settings and they're not like you say?
3. Yes, I know this is the solution (or using GitHub apps), the documentation I referred states this.
4. As said, we don't allow forks.
5. Yes, I know, this doesn't stop us, it's just one mor approval step we don't need.

This post doesn't answer my question really only states what I really know and got confirmation out of the documentation. The question was when was this applied. According to document history, changes were done to the documentation around this the 22nd of May (protected by a feature flag), but I can say for certainty that it wasn't like this last week (last run WITHOUT this was 10th of June).

[Fatiihunza89]

This is often caused by a GitHub Actions security policy change, not necessarily by the action itself.

A few things to check:

Has the repository recently changed its Actions permissions or fork pull request settings?
If the PR is being created by a bot account or GitHub App, GitHub may now treat it as an external contributor and require workflow approval.
Check Settings → Actions → General for options related to workflow approvals and fork pull requests.
If the PR author is no longer considered a trusted contributor, GitHub will require a maintainer to approve workflow runs before they execute.
Review your organization's security policies, as an org-level setting can override repository settings.

If this behavior started suddenly without any workflow changes, it's likely due to a repository, organization, or GitHub security setting update rather than a problem with the action itself.

Can you share which action you're using and whether the PRs are created by a bot, GitHub App, or another workflow? That will help narrow down the cause.

[dozer75]

Hi,

I know everything around the issue why it happens, how to fix it and so on, but my question was more really WHEN this came because the documentation history has a change for this the 22nd of May, but we didn't experience this change before yesterday, and I need to document this.

But to answer your questions, no nothing has changed in the repo between the last time we ran through these workflows that now are a issue (10th of June) and yesterday (17th of June). The settings are correct and this is not related to any forks because we don't allow forks. The identified action (one of them) that caused it is in the original post, and I know it is because of the github-actions[bot] usage.

[adeshkashyap]

hi, GitHub rolled out a change that now requires workflow approval when a PR is created or updated by github-actions[bot], even for branches within the same repository (not just forks). The documentation update on May 22nd appears to be when this was first flagged internally behind a feature flag, and based on your timeline — working fine on June 10th, broken on June 17th — the enforcement likely reached your organization sometime in that window during a gradual rollout.
GitHub typically doesn't announce these incremental policy enforcements publicly, which is why there's no clear "activated on X date" notice. To get the exact date for your documentation, your best option is to contact GitHub Support directly — they can confirm precisely when the policy was applied to your organization.

[dozer75]

Thanks for the answer,

GitHub starts to annoy me just more and more...