Push protection ruleset bypass not prompting as described

[Lawls91]

Select Topic Area

Bug

Body

I have created a simple push protection ruleset with the bypass list set to the Repository admin role. The description of the bypass says "the selected actor(s) will be prompted to bypass". However, as a repo admin when I push to a file that hits this ruleset, it just automatically bypasses it without a prompt.

I have tried committing with both git CLI and through the github webview and both just bypass the rule automatically without any prompt

[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. ⭐

[patrick-knight]

Thanks for the note @Lawls91.

Looks like we carried over the language in the UI from branch and tag rules which allow bypassing via a PR which is not a flow a push invokes. We'll get a internal issues created to ensure the copy on the bypass UI is aligned with the type of rule being selected.

[jwadsack-e3]

@patrick-knight thanks for opening an internal issue to address this. Your proposed solution would fix the incorrect statement but I'd actually prefer that bypassing push rules required confirmation.

In general we don't want anyone pushing to main but there are a few people who should be allowed to in an emergency or specific situations. Having a confirmation would prevent those authorized from accidentally pushing to main when they don't intend to.

The alternative is that we don't have a bypass rule and only add it during an incident, which we will document in our incident playbook. This is ok (it defines a clear privilege escalation action), but isn't ideal.

[patrick-knight]

You probably also want to add a branch ruleset here as push rules, are ref agnostic and wouldn't only target main but any branch.

With a branch rule you can better control specific protections, and allows you to bypass for PRs but not pushing to main

[Sarabadu]

We are having this same issue
Having the always option does not prompt the user, and does not requires a force push... simple accept the push to main. I do not fully follow from your comments @patrick-knight, is that the expected behaviour?

Our expectation is to at least request a force push to the actor from CLI

[vinodbavage31]

What you’re seeing is actually the current intended behavior for push protection rulesets. When a bypass actor is allowed (like a repo admin) and the ruleset applies to a push, GitHub automatically lets the push go through—it doesn’t prompt or require a force push. The “prompt to bypass” text in the UI comes from branch/tag rules and doesn’t fully apply to push rules, which is why it can be misleading.

If your goal is to require confirmation before bypassing, the recommended workaround is to use branch protection rules instead of a push ruleset. Branch rules allow bypass actors to be prompted when merging PRs, but there’s currently no built-in prompt for direct pushes, even from CLI.

So yes, the behavior you’re seeing is expected given how push rules are implemented today, and it’s mainly a UI wording mismatch.

[dverbru]

My team and I were also bitten by this UI trap. I agree that a confirmation dialog in PRs would be much more desirable than the current unconditional and silent bypass.

[luca-piombino-deltatre]

Let me start by saying that i would prefer if this was actually implemented (or if additional separated options were provided to configure the prompt behavior if needed).

Now, that said, if this is not planned, how much time does it take to fix some text?
I understand prioritization, but the text is clearly confusing AND misleading.
It's a "pit of failure" kinda thing...

[luca-piombino-deltatre]

I was looking at the options again and i think something does not feel right...

What's the difference between the first and the last option if there is no way to setup prompt/confirmation?

In my opinion, once the prompt concept is removed, then there is no significant difference...

And this kinda confirm it

https://github.blog/changelog/2025-09-10-github-ruleset-exemptions-and-repository-insights-updates/

New ruleset bypass type
GitHub repository rulesets now let you exempt specific actors (roles, teams, or GitHub Apps) from all enforced rules with a new exempt bypass type. Unlike a standard bypass (i.e., a “break glass” action that requires an explicit actor bypass and generates prominent audit signals), an exemption silently skips enforcement. Use it for trusted, high-volume automation or migration scenarios where friction would otherwise slow you down.