---
title: "How do I fix GitHub code scanning alerts?"
fixMetaTitle: "Fixing code scanning alerts"
slug: github-code-scanning-alerts
severity: medium
category: Configuration
summary: "Open the alert under Security and quality, read its path and fix guidance, fix it in a pull request, and dismiss it only when it is wrong or does not apply."
platforms:
  - GitHub
updated: "2026-10-29"
published: "2026-10-26"
related:
  - check-your-coding-agents-security-work
  - outdated-dependencies
  - hallucinated-and-malicious-npm-packages
  - secrets-committed-to-git
securityClaim: true
---

In your repo's **Security and quality** tab, click **Code scanning** and open the alert. Read its data-flow path and fix guidance. Fix with **Generate fix** (Copilot Autofix, on all public repos, no Copilot subscription), your own coding agent, or a manual PR, then let code scanning re-run. Dismiss only alerts that are wrong or don't apply, with the matching reason.

GitHub's [assessing alerts guide](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/assess-alerts) says you need write permission to see the list of alerts. Since GitHub made agentic autofix generally available on October 15, 2026, some alert pages show **Assign to Copilot** where Generate fix used to be. GitHub's [changelog](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/) says that when agentic autofix is enabled, it "replaces the free Generate Fix option on individual code scanning alerts with an Assign to Copilot button." Each agentic session uses AI credits and GitHub Actions minutes, and GitHub's [Advanced Security billing page](https://docs.github.com/en/billing/concepts/product-billing/github-advanced-security) says it uses those credits "even when the repository is public". Read the section on that choice below before you click.

## What do the severity levels mean, and which alerts block my PR?

Every code scanning alert has a severity of Error, Warning, or Note. Each security alert found with CodeQL also has a security severity of Critical, High, Medium, or Low. GitHub's [code scanning alerts page](https://docs.github.com/en/code-security/concepts/code-scanning/code-scanning-alerts) says that when an alert has a security severity, code scanning displays and uses it in preference to the severity.

In a pull request, code scanning reports through a check called **Code scanning results**. GitHub's [pull request triage guide](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/triage-alerts-in-pull-requests) says the check fails when it finds any problem with a severity of `error`, `critical`, or `high`. When every result is lower, the alerts are treated as warnings or notes and the check succeeds. You can change which severities fail the check in the repository settings. GitHub's [default setup page](https://docs.github.com/en/code-security/how-tos/find-and-fix-code-vulnerabilities/manage-your-configuration/edit-default-setup) says rulesets can stop a pull request from merging when a required tool finds an alert of a severity the ruleset names. Depending on branch protection rules, the Code scanning results check can also be a required check that blocks the merge until it passes.

Alerts that are not in application code get a label: Generated, Test, Library, or Documentation. GitHub assigns these by file path, and you can't set them by hand. Two more rules explain alerts that seem to move around. The alert page shows the alert's status on the default branch, even when you opened it from another branch. And a pull request only shows an alert when every line of code the alert identifies is in the pull request diff.

## How to check in 5 minutes

1. Open the repository, click the **Security and quality** tab, then click **Code scanning** in the left sidebar. By default the list shows alerts on the default branch.
2. Pick the "Only alerts in application code" filter, or type `autofilter:true` in the search box, to hide alerts labeled as generated, test, library, or documentation code. Narrow further with filters such as `is:open severity:high branch:main`.
3. Click an alert. Read the description, then click **Show more** for CodeQL's guidance on how to fix the code.
4. If the alert is about data flow, click **Show paths**. The path view lists each step from the source, where user-provided data enters the code, to the sink, where it is used in a potentially unsafe operation.
5. Decide whether it is real. GitHub's triage guide says the path view is how you check whether the data is untrusted, or whether the analysis missed a sanitization step between the source and the sink.
6. If an alert is open on one branch and fixed on another, read the **Affected branches** section on the right of the alert page.

## Should I click Generate fix or Assign to Copilot?

They are two different features. GitHub's [autofix overview](https://docs.github.com/en/code-security/concepts/code-scanning/autofix-for-code-scanning) describes both, and says "Each agentic autofix agent session consumes AI credits and GitHub Actions minutes, while Copilot Autofix suggested fixes don't consume AI credits."

- **Generate fix** is Copilot Autofix. It writes one suggested change for one alert, which you review and apply. It is enabled by default for any repository that uses CodeQL, unless an administrator turns it off. You don't need a Copilot subscription. It is available on all public repositories on GitHub.com, and on internal or private repositories owned by organizations and enterprises with a GitHub Code Security license.
- **Assign to Copilot** is agentic autofix. It starts an agent session that explores the codebase, generates and validates a fix, and opens a pull request. GitHub's [resolving alerts guide](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/resolve-alerts) says Copilot typically opens a draft pull request within a few minutes, and that you can select up to 25 alerts at once, which makes one agent session and one pull request. It only works on alerts on the default branch. You don't need a Copilot license, but each session consumes Code Security AI Credits and GitHub Actions minutes.
- **Your own coding agent**, such as Claude Code or Cursor, with the prompt on this page. It lists the alerts first and asks before it dismisses anything.

Agentic autofix validates a fix by re-running CodeQL with the code scanning query suite. The autofix overview says it can't confirm fixes for alerts from custom CodeQL queries, the `security-extended` query suite, or third-party tools.

For an eligible public repository owned by your personal account, a repository administrator can turn agentic autofix on or off. GitHub says agentic autofix is not available for repositories owned by Enterprise Managed Users. GitHub's [agentic autofix access guide](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/managing-access-to-agentic-autofix-for-code-scanning) gives the path: **Settings**, then **Advanced Security** in the "Security and quality" section of the sidebar, then the **Agentic Autofix** toggle in the "Code Security" section. The same guide says to review how AI credits and Actions minutes affect your costs before you enable it. When it is off, Generate fix stays available where Copilot Autofix supports the alert. The October 15 changelog describes availability for GitHub Code Security and GitHub Advanced Security customers on GitHub Enterprise Cloud, including data residency, and says access requires a Copilot billing method. The access guide also describes availability for public repositories on GitHub.com and gives instructions for eligible personal-account public repositories. These sources describe different scopes, so public visibility alone should not be treated as proof of eligibility.

## Can I trust the fix?

Not without checking it. GitHub's [responsible use page](https://docs.github.com/en/code-security/responsible-use/security-and-quality-ai-features) lists the limits of Copilot Autofix. The model is non-deterministic, so the same alert can get a different suggestion, or none, on another try. A suggestion can have syntax errors, sit at the wrong location, or change what the program does. GitHub says the system "may suggest fixes that fail to remediate the underlying vulnerability or introduce new vulnerabilities."

Dependencies need extra care. The same page says a suggested fix can add or update dependencies, that the system doesn't know which versions are supported or secure, and that it "may suggest fabricated dependencies published under statistically probable names. Always verify dependency changes before merging." Check any new package the way [Is the npm package your AI agent added safe?](/issues/hallucinated-and-malicious-npm-packages) describes.

Treat every fix the same way, whether it came from Generate fix, Assign to Copilot, or your own agent. Read the diff, run your tests, and let code scanning run on the pull request. GitHub's responsible use page says to verify that CI still passes and that the alert is shown as resolved before you merge. The autofix overview says: "Always review and test the generated changes before you merge the pull request."

## When is it OK to dismiss an alert?

Dismiss an alert only when you don't think it needs a fix. GitHub's resolving alerts guide gives two examples: an error in code that's used only for testing, or a fix that would cost more effort than it is worth. When you dismiss an alert:

- It is dismissed in all branches.
- It moves to the Closed list, where you can reopen it.
- The reason is recorded, and an optional comment goes on the alert timeline.
- Next time code scanning runs, the same code won't generate an alert.

Explore the alert first, then click **Dismiss alert** and choose the appropriate reason offered by GitHub. For API requests, the [code scanning REST API](https://docs.github.com/en/rest/code-scanning/code-scanning) documents four dismissal reasons: `false positive`, `won't fix`, `used in tests`, and `mitigated`. GitHub's resolving alerts guide says the reason chosen in the UI menu may affect whether a query remains included in future analysis. Add a comment that says why. If you later find the alert does need a fix, reopen it from the Closed list and fix it like any other alert.

If an agent offers to dismiss alerts to make a check pass, that is not a fix.

## How to fix

### GitHub

Fix the code in a pull request, so code scanning analyzes the change before it reaches the default branch. GitHub's resolving alerts guide says that when code scanning runs on pull requests, a pull request with your correction tests that the fix doesn't introduce new problems.

1. Open the alert. If Copilot Autofix can suggest a fix, click **Generate fix** at the top of the page. When the suggestion is ready, click **Create PR with fix** at the bottom. GitHub creates a branch from the default branch, commits the fix, and opens a draft pull request that you can test and edit.
2. If you see **Assign to Copilot** instead, agentic autofix is on for the repository. Read the [cost and eligibility notes in the full guide](/issues/github-code-scanning-alerts) first. Copilot says in its pull request if it couldn't validate the fix or thinks the alert might be a false positive, and you can ask it for changes by mentioning it in a pull request comment.
3. To fix it yourself or with your own agent, make the change on a branch and open a pull request. Check any new dependency before you add it.
4. On a pull request, Copilot Autofix can also post a suggested fix as a comment on an alert. It covers a subset of CodeQL queries. Click **Dismiss suggestion** if you don't want it.
5. Before you merge, check that your tests pass and that the alert is shown as resolved.

## How do I list alerts from the command line?

The [GitHub CLI](https://cli.github.com/manual/gh_api) can call the code scanning REST API. Run it inside your repository's folder. `gh api` replaces `{owner}` and `{repo}` with the current directory's repository, and `--paginate` requests every page of results:

```bash
gh api "repos/{owner}/{repo}/code-scanning/alerts?state=open&per_page=100" --paginate \
  --jq '.[] | [.number, .rule.id, (.rule.security_severity_level // .rule.severity), .most_recent_instance.location.path, .most_recent_instance.location.start_line] | @tsv'
```

That prints one line per open alert: the alert number, the rule id, the security severity (or the severity when there is none), the file, and the line. Notes from the REST API reference:

- Add `&severity=high` to the query string to filter. The accepted values are `critical`, `high`, `medium`, `low`, `warning`, `note`, and `error`.
- `per_page` goes up to 100.
- The endpoint returns 403 when GitHub Advanced Security is not enabled for the repository.
- A personal access token (classic) needs the `security_events` scope, or `public_repo` for public repositories only. A fine-grained token needs the "Code scanning alerts" repository permission (read).
- The update endpoint takes `state`, `dismissed_reason`, and `dismissed_comment`. Read each alert before you dismiss it this way.

## Agent prompt

```text
You are triaging GitHub code scanning alerts on this repository. Do not add features.

1. Run: gh api "repos/{owner}/{repo}/code-scanning/alerts?state=open&per_page=100" --paginate
2. For each open alert, show the alert number, rule id, file, line, and severity. Use security_severity_level when it is set.
3. For each alert, say whether it looks real or like a false positive, and why. When the alert is about data flow, trace the path from the source to the sink in the code and say whether anything sanitizes the data on the way.
4. Fix the real ones in one pull request. Do not add a new dependency unless I approve it by name first.
5. Do not dismiss any alert without asking me first. When I agree, dismiss it with the matching reason (false positive, won't fix, used in tests, or mitigated) and a comment that says why.
6. Do not turn off a check, change the code scanning setup, or dismiss alerts to make a check pass.

Output a table with: alert number, rule, file and line, severity, real or false positive, why, and what you changed.
```

## FAQ

### Is GitHub code scanning free?

Yes, on public repositories on GitHub.com. Private repositories need GitHub Code Security, which you can only buy on a GitHub Team or GitHub Enterprise plan. GitHub also lists Copilot Autofix as available for public repositories by default. See [GitHub code scanning](/tools/github-code-scanning) for how to turn it on.

### Does Assign to Copilot cost money?

It can. Each agentic autofix session consumes Code Security AI Credits and GitHub Actions minutes, and GitHub's billing page says the credits are consumed even when the repository is public. If the billed account has included AI credits from a GitHub Copilot entitlement, usage draws from those first, and usage after that is metered. Generate fix (Copilot Autofix) doesn't consume AI credits.

### Why don't I see code scanning on my private repo?

Code scanning on a private repository needs a GitHub Code Security license, which is sold on GitHub Team and GitHub Enterprise plans. GitHub's billing page says that if you change a public repository to private and don't pay for Advanced Security, its Advanced Security features are disabled for that repository. You also need write permission to see the alert list.

### Which dismiss reason do I pick for test code?

`used in tests`, for an alert in code that only runs in tests. Add a comment that says so. Alerts in files GitHub recognizes as test code already carry the Test label, and the `autofilter:true` filter hides them from the list without dismissing them.

## Sources

- [GitHub Docs: Resolving code scanning alerts](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/resolve-alerts)
- [GitHub Docs: Code scanning alerts](https://docs.github.com/en/code-security/concepts/code-scanning/code-scanning-alerts)
- [GitHub Docs: Triaging code scanning alerts in pull requests](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/triage-alerts-in-pull-requests)
- [GitHub Docs: Assessing code scanning alerts for your repository](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/assess-alerts)
- [GitHub Docs: About autofix for code scanning](https://docs.github.com/en/code-security/concepts/code-scanning/autofix-for-code-scanning)
- [GitHub Changelog: Agentic autofix for code scanning alerts general availability](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/)
- [GitHub Docs: GitHub Advanced Security license billing](https://docs.github.com/en/billing/concepts/product-billing/github-advanced-security)
- [GitHub Docs: Managing access to agentic autofix for code scanning](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/managing-access-to-agentic-autofix-for-code-scanning)
- [GitHub Docs: Application card for GitHub security and quality AI features](https://docs.github.com/en/code-security/responsible-use/security-and-quality-ai-features)
- [GitHub Docs: REST API endpoints for code scanning](https://docs.github.com/en/rest/code-scanning/code-scanning)
- [GitHub CLI manual: gh api](https://cli.github.com/manual/gh_api)
- [GitHub Docs: About GitHub Advanced Security](https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security)
- [GitHub Docs: GitHub security features](https://docs.github.com/en/code-security/getting-started/github-security-features)
- [GitHub Docs: Editing your configuration of default setup](https://docs.github.com/en/code-security/how-tos/find-and-fix-code-vulnerabilities/manage-your-configuration/edit-default-setup)