GitHub · Pull requests · Secret scanning · Checked October 26, 2026

GitHub: secret scanning alerts block the merge

"Require secret scanning alerts are resolved" is a rule for rulesets that target branches. It blocks a pull request from merging when a secret scanning scan has not completed for the pull request's head commit, or when a commit in the pull request introduced an open secret scanning alert that matches a secret type selected in the ruleset. The rule is in public preview and subject to change (GitHub's blocking pull request merges that contain secrets, checked October 26, 2026).

PATCH /repos/OWNER/REPO/secret-scanning/alerts/ALERT_NUMBER
{ "state": "resolved", "resolution": "revoked" }

What the rule checks

The scan of the head commit: until a secret scanning scan completes for the pull request's head commit, the rule blocks the merge, even when no alert is open.
Alerts the pull request introduced: an open alert introduced by a commit in the pull request blocks it when its secret type is one the ruleset selects: provider patterns, custom patterns or generic patterns. AI-detected secrets are not supported (GitHub's available rules for rulesets).
What the repository needs: GitHub Secret Protection or GitHub Advanced Security enabled, and secret scanning enabled.
Where it is set: in a branch ruleset of the repository, or in a ruleset of the organization for the repositories it targets, under "Branch protections".

Why the merge still waits after a fix

Removing the secret does not close the alert: secret scanning does not automatically close alerts when the token has been removed from the repository; they have to be closed by hand in the alert list (GitHub's resolving alerts from secret scanning).
A new head commit: after all blocking alerts are closed, the rule can still block the merge until a secret scanning scan completes for the pull request's head commit.
Treat the secret as compromised: GitHub recommends treating a secret committed to a repository as compromised: review and update the services that use it, and for a GitHub personal access token, delete it and create a new one.

What to do

Close each blocking alert: in the repository's "Security and quality" tab, under "Vulnerability alerts", open "Secret scanning", open the alert, choose a reason in "Close as", optionally add a comment, and click "Close alert". Every open alert that matches the secret types the ruleset selects has to be closed.
Through the REST API: "Update a secret scanning alert" sets state to resolved with a resolution of false_positive, wont_fix, revoked or used_in_tests; the authenticated user must be an administrator for the repository or for the organization that owns it (GitHub's REST API endpoints for secret scanning).
No alert, still blocked: wait for the scan of the head commit to complete.
Find the rule: anyone with read access to a repository can view its active rulesets (GitHub's about rulesets); the secret types the rule selects decide which alerts count.

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows a pull request's reviews, checks and conversations next to the diff, and merges it with the methods the target branch allows. When a pull request is blocked, its merge checks say that the rules of the target branch are not met yet, and name the rules they can read from the branch's rulesets. GitHub's REST API documentation for rules gives no type for this rule yet, so the plugin does not name it. The review inbox, diffs and conversations are free; approving, commenting, resolving and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.