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

GitHub: the merge waits for code scanning results

A branch ruleset can require code scanning results ("Require code scanning results"). If the repository is configured with code scanning, a pull request into that branch is then not merged while a required tool finds a code scanning alert of a severity the ruleset defines, while a required tool's analysis is still in progress, or while a required tool is not configured for the repository (GitHub's available rules for rulesets and set code scanning merge protection). Classic branch protection has no such setting; it is the ruleset rule code_scanning (checked October 26, 2026).

GET /repos/OWNER/REPO/rules/branches/BRANCH
[{ "type": "code_scanning", "parameters": { "code_scanning_tools": [
    { "tool": "CodeQL", "alerts_threshold": "errors", "security_alerts_threshold": "high_or_higher" } ] } }]

What the rule checks

Each tool, with two levels: for every tool the ruleset names, "Alerts" is None, Errors, Errors and Warnings or All, and "Security alerts" is None, Critical, High or higher, Medium or higher or All. Through the REST API they are alerts_threshold (none, errors, errors_and_warnings, all) and security_alerts_threshold (none, critical, high_or_higher, medium_or_higher, all): the levels at which results that raise alerts, or security alerts, block a reference update (GitHub's REST API endpoints for rules).
Results for both sides: when the rule is configured, code scanning must be enabled and have results for both the commit and the reference being updated.
Severity and security severity: every code scanning alert has a severity of Error, Warning or Note; each security alert found by CodeQL also has a security severity of Critical, High, Medium or Low, and when an alert has one, code scanning displays and uses it in preference to the severity (GitHub's code scanning alerts).
Reading the rule: "Get rules for a branch" returns all active rules that apply to a branch, at whatever level they are configured; rules in rulesets that only evaluate, or are disabled, are not returned.

Where the results show on the pull request

The check: for all configurations of code scanning, the check that contains its results is "Code scanning results", with each analysis tool's results shown separately, and new alerts on lines the pull request changed shown as annotations. By default the check fails if it finds any problem with a severity of error, critical or high; the repository settings can change those levels (GitHub's triaging code scanning alerts in pull requests).
When results reach a pull request: they appear as check results and annotations where code scanning is configured as a pull request check (by default limited to pull requests that target the default branch), or scans each time code is pushed, with the results mapped to any open pull requests.
The analysis checks: with the CodeQL analysis workflow, a "CodeQL / Analyze (LANGUAGE)" check runs for each language before the results check. It may fail on configuration problems, or when the pull request breaks the build for a language the analysis compiles (C/C++, C#, Go, Java, Kotlin, Rust and Swift, for example).

What to do

Read which tool holds it: the ruleset names the tools and their levels; the "Code scanning results" check shows each tool's results, and "View all branch alerts" opens every alert on the analyzed branch.
An alert at a blocking level: fix it in the pull request (anyone with push access can; a new commit runs the checks again, and a fixed alert is closed and its annotation removed), or dismiss the alert from its annotation if it is not a real problem.
Analysis in progress or failing: wait for the analysis checks, or open the failing "Analyze" check on the Checks tab; a pull request that breaks the build of a compiled language fails the analysis.
A tool not configured, or no results: make sure the required tool runs for this pull request and for its target branch; a pull request check is by default limited to pull requests into the default branch, so a ruleset on other branches needs the analysis to run there too.
Conversations on alerts: if the branch also requires conversation resolution, comments on code scanning alerts count (see the merge waits for conversations).

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 GitHub calls the pull request blocked, its merge checks name what they can read: required checks that have not reported, a review still required, unresolved conversations and unsigned commits the rules hold against it, and the rule on the most recent push. Its checks list shows the code scanning checks with the others, and when the branch's rulesets require code scanning results, the merge checks of a blocked pull request say so and name each required tool with the alert levels that block. 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.