Strictly speaking, CodeQL does not know about closed alerts at all. It’s just an analysis tool that takes a particular source tree and produces a list of alerts that are present in that source tree. The alert list, as a SARIF file, is then uploaded to GitHub for further processing by a different component known as Code Scanning. It is Code Scanning that compares results from different commits in a repository to decide that some alerts are “the same” between them, and others are “new” or “fixed”.

This might seem like useless pedantry, but the difference in naming is relevant for your question because CodeQL is the part you can see run. If you’re using the default Actions setup, you can see the mumblings of the CodeQL engine in the log tabs of your workflow run; if you’re an enterprise customer running your own CI infrastructure, you’ll have scripts that execute CodeQL directly.

However, after the web backend has received the SARIF file, the internals of what its Code Scanning component does are not directly visible to users. Alerts for each repository and commit are stored in an internal database. We provide some REST APIs that interact with it, but they’re not a direct view of the database, and except for SARIF uploads they mostly work on a level of abstraction where matching of alerts between different commits in a repo has already happened.

We’re aware that the Code Scanning experience with forked repositories is not very good. We’re working towards improvements here, but there are both technical and policy challenges to solve along the way, as well as competing demands on the relevant engineering teams, so some patience will be necessary.