Lock Down GitHub Review Dismissals Before a Bad Merge Clears Approval

Confirmed: GitHub now lets repository rulesets restrict who can dismiss pull request reviews. The July 7, 2026 changelog says the feature is generally available on github.com and can be configured through the UI, REST API, and GraphQL. For teams using protected branches, this closes a governance gap where too many writers could clear a blocking review before merge.

What changed

GitHub added a repository-ruleset option called "Restrict who can dismiss reviews" inside the "Require a pull request before merging" rule. Repository admins can choose the users, teams, and GitHub Apps allowed to dismiss reviews, using the same actor picker GitHub uses elsewhere in rulesets.

GitHub's docs now describe the setting in the rulesets rule list: if required reviews are enabled, admins can select the users, teams, or GitHub Apps that may dismiss reviews on branches targeted by that ruleset. The changelog says the feature is generally available for repository rulesets on github.com.

Why this is early

This is fresh platform governance news rather than a rumor. GitHub published the changelog entry on July 7, 2026, and the supporting docs already include the ruleset behavior.

It is still early operationally because many repositories keep review controls split between older branch protection rules, newer rulesets, CODEOWNERS, and admin bypass conventions. Teams should verify which mechanism actually applies to their default branch before assuming the new restriction covers every merge path.

Key takeaways

• GitHub rulesets can now limit review dismissal to named users, teams, and GitHub Apps.
• The setting is part of "Require a pull request before merging."
• GitHub says it is generally available for repository rulesets on github.com.
• Teams can configure it through the UI, REST API, or GraphQL.
• The useful audit is simple: list who can approve code, who can dismiss reviews, and who can bypass the ruleset.

Availability and access

The feature is available for repository rulesets on github.com. GitHub's rulesets docs say people with repository admin access, or a custom role with the "edit repository rules" permission, can create, edit, and delete repository rulesets.

Plan availability still matters. GitHub's docs say rulesets are available in public repositories with GitHub Free and Free for organizations, plus public and private repositories with GitHub Pro, Team, and Enterprise Cloud. Push rulesets have narrower plan coverage, but this review-dismissal setting sits in pull request rules.

Practical LinkLoot angle

Use this before giving agents, bots, or large contributor groups more merge authority. A pull request review is only useful if the wrong actor cannot erase the blocking review at the last minute.

Run this checklist on the default branch first:

• Confirm whether the branch is governed by a ruleset or classic branch protection.
• Enable required pull requests and required reviews where they are not already active.
• Restrict review dismissal to maintainers, release owners, or a small platform team.
• Check whether any GitHub App can dismiss reviews and why it needs that permission.
• Review bypass actors separately; dismissal controls do not replace bypass governance.

For agent-heavy development teams, pair this with LinkLoot's AI workflow automation guide: code agents should create auditable changes, not quiet paths around review.

What to verify before you act

• Check which ruleset targets your default branch and release branches.
• Verify who has repository admin rights or the custom role that can edit rulesets.
• Compare dismissal actors with CODEOWNERS, release owners, and on-call maintainers.
• Test the rule with a non-admin account before relying on it for a sensitive repository.
• Confirm whether REST or GraphQL automation updates the same setting in your governance scripts.

Source check

Confirmed by: GitHub's July 7 changelog confirms the generally available ruleset setting, the UI location, actor selection, and REST/GraphQL configuration paths. GitHub's rulesets documentation confirms the same restriction inside required review rules.

Context: GitHub's pull request review documentation explains what happens when a review is dismissed: the review becomes a review comment and the person dismissing it must add a reason. That context matters because review dismissal is not only a permission setting; it is part of the audit trail around blocked merges.