[Feature Request] Allow github actions to bypass branch protection rules in certain specific circumstances

[philomory]

There are workflows in which it is desirable to have the workflow itself make changes (such as updating a pom.xml, packages.json, CHANGELOG.md, etc.) on a branch which is otherwise protected from direct changes.

Some things that don't work (or don't work well):

• Simply disabling branch protection rules entirely for the branch in question isn't a feasible solution, because there are plenty of legitimate reasons to want branch protection rules in place.
• It's not possible to add the pseudo-user represented by the GITHUB_TOKEN to the "Restrict who can push to matching branches" list, but even if it were this wouldn't be a useful solution, because then any action from any branch could bypass the branch protection rules, making them too easily circumventable.
• You can create a "service user", add that service user to the "Restrict who can push to matching branches" list, create a Personal Access Token (PAT) for that service user, store the PAT in an environment secret, assign the relevant environment to your protected branch, and then have the workflow get the PAT from the environment, and then set up extra rules in all of your workflows triggerd by push events to make sure that they ignore any commits pushed by the service user (the way they'd ignore commits pushed using GITHUB_TOKEN). This more-or-less works, but it's a lot of work to replicate this set up across dozens of repositories, and it's really abusing a bunch of unrelated functionality for something that should be available out of the box.

My proposed solution is to add a checkbox under Branch Protection rules, "Allow Github Actions workflows run from matching branches to push commits back to the same branch". Checking this box would have two effects:

1. Workflows triggered by push events to the protected branch (which, given the branch is protected, will generally represent pull-request merges rather than remote pushes) will be allowed to push additional commits back to the protected branch as if they were being pushed by an individual user who was listed under "Restrict who can push to matching branches".
2. Workflows triggered by a workflow_dispatch event, where the workflow was dispatched from the protected branch (i.e. the workflow YAML file being executed is read from the protected branch) will be allowed to push additional commits back to the protected branch as if they were being pushed by an individual who was listed under "Restrict who can push to matching branches".

Note that in both cases, the workflow should only be permitted to push commits back to the same branch that the workflow is being executed from (or other, unprotected branches, as is already possible). A workflow should not be able to push commits to any other protected branch, not even a distinct branch that matches the same branch protection rule.

This feature request is inspired by a long-running discussion in the Github Community discussion boards; I felt it was worth bringing a concrete feature request to this Feedback repository, at this point.

NOTE: If you want to show your support for this feature request, please upvote it using the upvote button

rather than replying with a "+1". Replies like that just result in sending spam to everyone else interested in the issue, and importantly, don't even "count" when it comes to how much GitHub will prioritize the issue. They're just spam, they're not spam that also counts as a vote in any way.

[xakraz]

Also mentioned and requested here: https://github.community/t/allowing-github-actions-bot-to-push-to-protected-branch/16536

[brightshine1111]

Even though it wouldn't work in all use cases for all people, treating the github-actions bot as a full-fledged app so we can add it to protected branch pushers would be immensely useful in a number of situations.

E.g. at my company the main branch is gated by PRs; once a PR is merged that triggers the deploy workflow, and part of that workflow is simply pushing fast-forward commits to a minor version branch (e.g. if the current release should be v2.3.4, deploy will update the v2.3 branch to be even with main). We want to protect these minor versions branches so humans can't accidentally push to them and get them out of sync with main. The minor branches aren't critical to any other parts of our CI/CD pipeline otherwise, so simply being able to add the github-actions bot to that branch protection rule would be perfect in our situation.

[treeder]

This is the way.

Just let us add GitHub actions to this list:

[solarmosaic-kflorence]

FYI: https://github.blog/changelog/2022-05-17-consistently-allow-github-apps-as-exceptions-to-branch-protection-rules

[timothyjlaurent]

Thank you @daniel-res 👏 👏

This is the internet's only source for this information

[b3nk3]

I was able to add the App to the bypass list under branch protection with lesser permissions than @daniel-res.

Namely:

• Action
• PR
• Contents

[DoisKoh]

When I try to Allow specified actors to bypass required pull requests, I don't see any 'apps' to choose from. How do I allow GitHub actions to bypass this?

[christian-benseler-farm]

Same for me @DoisKoh

[ghost]

Did you previously install required app on your repository?

• https://github.com/<usernam>e/<repository>/settings/installations
• GitHub --> Repository --> Settings --> Integrations --> GitHub Apps
• Installing your own GitHub App

We use a own app for that and bellow is an example with a public one.

screenshots

[agaertner]

Just encountered this exact issue. This is certainly great to have for smaller hobby teams as well where you don't really want nor need to setup whole delivery pipelines.
I have setup simple automatic deployment on main which commits some changes like assembly version bumps, changelog, etc. However, I have to remove the branch protection for it to function which is bad for collaborations.

[Camuvingian]

Yes, GitHub, let's get this feature in please.

[cunhap]

Would also like this implemented. 👍

[rael-b]

That would be a great GA to implement!

[u-ways]

+1 I had to implement a walkaround to cater for such requirements which I do not encourage following...

Update: If you're very keen, you can see multiple ideas/solutions posted across the board linking to this issue.

[andreaagudo3]

how did you do it?

[maazmmd]

Can you please post the workaround

[madhifallah]

does this fit your need ? https://github.blog/changelog/2022-08-18-bypass-branch-protections-with-a-new-permission/

[dedece35]

+1 for our open-source organization (not GitHub Entreprise :( )

[philomory]

I don't think this fits the full need even for Github Enterprise customers. This is basically somewhere between non-solution number two and number three from the original post; that custom role can't be applied to the GITHUB_TOKEN psuedo-user, you have to assign it to an actual user; if you could assign it to the GITHUB_TOKEN psuedo-user, it wouldn't solve the problem acceptably because then anyone who could push to any branch, could push a workflow that interfered with protected branches; and if you instead assign the custom role to a "service account" user and make different service account users for workflows on different branches, well, that's non-solution number three: it works, more or less, but it's way too complicated to scale.

[frankinspace]

If you have an organization (on public github); you should be able to use the solution proposed in https://github.com/orgs/community/discussions/13836#discussioncomment-2901138

That's how we solved it; we have a custom dummy "CICD" github App and our workflows that make commits back to protected branches use the CICD github app credentials when committing. Then in the repository settings we allow the CICD App to skip status checks.

I still agree though it would be better if we didn't have to create our own app and we could just allow the GITHUB_TOKEN to skip status checks directly.

[philomory]

@frankinspace Doesn't that solution still fail in that someone could e.g. push a new workflow to a non-protected branch, that workflow would run with the credentials of the app, and could therefore push to a protected branch? Essentially meaning that the protected branch is not protected?

[frankinspace]

@philomory Yes, that is still a problem. IMO that's something I can tell my developers to not do. I still agree with your feature request and consider what I described an acceptable workaround until GH can resolve it properly.

[bigman73]

Also interested in a solution - I'm trying to auto bump the version but the branch protection rule I have on main branch doesn't allow it.

[Kav-K]

Also looking for a solution! I have a python-black formatter that pushes code to the main branch but the protection rules won't allow it

[airtonix]

in your case, you should do that on your PRs: do auto formatting commits to PRs only.

[thislooksfun]

I'm running into this issue as well. I use semantic-release to automatically update my package whenever my main branch is updated, and I use @semantic-release/git to commit the updated version and changelog back to the branch. However, I also want to enable required status checks so I can have that peace-of-mind (and also use auto-merge). But I can't, because if I turn it on the action can't push the version update anymore. Having a setting (either in the branch protection rules as suggested above, or in the action itself using the new permissions setting) would be a huge help for getting my setup clean and efficient.

[GuySartorelli]

+1 for this being part of the permissions in the workflow/action itself. There are some workflows where we want to be able to bypass branch protection rules - but we don't want to just blanket allow all workflows to bypass those protections.

[satonotdead]

Can we bypass the permission rules with Gitbook?

We are facing the same issue but within the same company (!)

[vagenas]

As a simplification of the "service user" approach outlined by the OP: for the commit(s) pushed by the "service user", one can consider using [skip ci] to suppress status checks without adding any extra rules in the workflows (see https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs).

[bigman73]

As a simplification of approach number three, one can consider using [skip ci] in the respective commit message(s) to suppress status checks without adding extra rules in the workflows (see https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs).

Not sure I'm following you. The idea is to have CI workflows run, not skipped, for example to auto increment versions.

[thislooksfun]

This isn't actually about getting workflows to run or not run at all, is about being able to have workflows push directly to a push-protected branch. [skip-ci] doesn't skip branch protection rules.

[vagenas]

I am referring to the third approach outlined by the OP, i.e. enabling pushing to the protected branch by explicitly allowing a "service user" to do so in the branch protection rules and then using the "service user" via a PAT accessed through an environment secret.

My comment was that, in this context, you do not necessarily have to (copying from the OP):

[...] set up extra rules in all of your workflows triggerd by push events to make sure that they ignore any commits pushed by the service user [...]

but you could rather just use [skip-ci] in those commits instead.

[ohmantics]

[skip ci] would work for the case mentioned above of @semantic-release/git trying to push release-related changes (package.json, CHANGELOG, etc.)

[sebaacuna]

So glad I read as far as your comment @vagenas , totally solved my issue where I already had the app (service account) set up but wanted a simple way to prevent the pushes to loop. Adding [skip ci] to the commit message saved the day.

[robertleeplummerjr]

Github, this is a need for full automation after deploys. PLEASE consider this soon.

[scheying]

+1

[eggduzao]

Your critique of the common workarounds is fair: PATs and bot users are clunky; letting raw GITHUB_TOKEN bypass would be dangerous.

The checkbox idea is good in spirit-it expresses the least-privilege intent you want-but it would need a few guardrails (see below), otherwise it recreates the very risks branch protection exists to mitigate.

First, I can think of some issues with the raw idea:

• Self-escalation via workflow edits: if a PR can change a workflow on that branch and then gets merged, the new workflow could immediately push arbitrary commits. Any "auto-allow push-back" needs guardrails (example is: "only allow after required checks", "only on workflow_run triggered from a trusted ref").
• Supply-chain surface: permitting writes from CI is a classic escalation vector without strong scoping and logging (see numerous advisories and discussions urging caution). 

If GitHub would be designing such checkbox, I'd insist on all of these guardrails:

1. Same-ref Only: workflow must run from commit already on the protected branch; can only push to that same branch. (No cross-branch writes.) 
2. Post-merge Trigger Only: allow on workflow_run where the triggering workflow was on the protected branch and all required checks passed for that commit.
3. Ephemeral, Branch-bound Token: write permission limited to contents: write on that branch only, bound to the "run ID"/"attempt"; expires at job end.
4. No-ops on Workflow files: disallow pushes that modify files under ".github/workflows/" in the same operation (avoid "grant -> rewrite workflow -> widen power").
5. Audit and Provenance: require signed commits with OIDC provenance, and show "bypass via workflow" in the branch protection audit log.
6. Repo Opt-in, Rule-scoped: toggle lives inside the specific branch protection rule, off by default.

So, I can see why this isn't Github priority ATM. But I'd vouch for it.

[cjnoname]

+1

[Zetjen]

+1

[schmocker]

+1

[GigiusB]

+1

[smiffy6969]

Use deploy keys...

Add a ruleset override on deploy keys.
Add a new deploy key to repo.
Add the private key as secret value on same repo.

Get secret value in workflow, perform your git a actions using the key.

I have had some issues getting the key to work, but you just need to enforce the key to use in the GitHub command. I think I exported the GitHub command to a var the ran it with shh key defined.

I can verify it then allows read and write if yous et it on the key to the repo if override allowed on ruleset.

If you get permission denied it's this problem. There is some issue with workflow using the deploy key in the git command so you have to mess a bit to get it going.

GIT_SSH_COMMAND="ssh -i github_actions_deploy_key -o IdentitiesOnly=yes -o StrictHostKeyChecking=no" git push origin develop

That's what worked for me, no joy with a single CMD but exporting and calling git worked in workflow.

[sbellone]

Good news, no need for the complicated git command, the checkout action permits to pass a ssh key in parameter:

steps: - name: Checkout codeuses: actions/checkout@v4with: ssh-key: ${{secrets.DEPLOY_KEY }}

See my complete answer here: https://github.com/orgs/community/discussions/25305#discussioncomment-10728028

[qoomon]

to get rid of managing long living credential you could try my action to generate temporary credentials without any long living credentials to manage https://github.com/qoomon/actions--access-token

[Barakmu]

Ok

[sherbakovdev]

+1

[MissingRoberto]

+1

[Barakmu]

What is about?

…

On Tue, 11 Nov 2025 at 11:29, zinzoch ***@***.***> wrote: What is the problem ask your capitol Sent from [Proton Mail](https://proton.me/mail/home) for Android. -------- Original Message -------- On Monday, 11/10/25 at 16:57 sherbakovdev ***@***.***> wrote: > +1 > > — > Reply to this email directly, [view it on GitHub]( #13836 (comment)), or [unsubscribe]( https://github.com/notifications/unsubscribe-auth/BZQTMBA4CHLHRRQR5CTJ7LT34CYVVAVCNFSM5SAQI6N2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCNBZGI3DGNBY ). > You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#13836 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOK7YDJ5WUUHUNSST6D6BIL34HCC7AVCNFSM5SAQI6N2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCNBZGM2TOOBW> . You are receiving this because you commented.Message ID: ***@***.***>

[Barakmu]

+2

…

On Tue, 11 Nov 2025 at 11:22, Roberto Jiménez Sánchez < ***@***.***> wrote: +1 — Reply to this email directly, view it on GitHub <#13836 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOK7YDPUVPYSWI6GJU7BTZL34HBJFAVCNFSM5SAQI6N2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCNBZGM2TONBW> . You are receiving this because you commented.Message ID: ***@***.***>

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams.
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences.
• GitHub staff may reach out for further clarification or insight.
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Barakmu]

Thank you for your response.

…

On Fri, 28 Nov 2025 at 16:51, github-actions[bot] ***@***.***> wrote: *💬 Your Product Feedback Has Been Submitted 🎉* Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. *Here's what you can expect moving forward ⏩* - Your input will be carefully reviewed and cataloged by members of our product teams. - Due to the high volume of submissions, we may not always be able to provide individual responses. - Rest assured, your feedback will help chart our course for product improvements. - Other users may engage with your post, sharing their own perspectives or experiences. - GitHub staff may reach out for further clarification or insight. - We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback. *Where to look to see what's shipping 👀* - Read the Changelog <https://github.blog/changelog/> for real-time updates on the latest GitHub features, enhancements, and calls for feedback. - Explore our Product Roadmap <https://github.com/orgs/github/projects/4247>, which details upcoming major releases and initiatives. *What you can do in the meantime 💻* - Upvote and comment on other user feedback Discussions that resonate with you. - Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots. As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ — Reply to this email directly, view it on GitHub <#13836 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOK7YDKISI4LAVJTZZOJRTL37B4P5AVCNFSM5SAQI6N2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCNJRGA3TIMJX> . You are receiving this because you commented.Message ID: ***@***.***>