GitHub CodeQL Plans to Remove All-Platform Bundles in 2027

CodeQL 2.27.0 retires the single-bundle download assumption​

GitHub’s deprecation notice changes the distribution model for CodeQL, the static-analysis engine behind GitHub code scanning. Static analysis examines code for potential problems; this announcement concerns the packages used to install that engine, rather than the retirement of code scanning or its security queries.

Previously, the all-platform bundle supplied binaries for the platforms included in that distribution. A team could therefore build its download process around one archive name, even when the machines consuming it differed. GitHub now directs users to choose a platform-specific bundle for their supported operating system and architecture.

The two named archives represent different compression formats for the all-platform bundle. Switching from .tar.gz to .tar.zst does not resolve the deprecation. Both filenames are covered by the notice; the required change is from the combined package to an appropriate platform-specific package.

GitHub’s CLI setup documentation explains why administrators should retain the bundle approach during this migration: it recommends the bundle to keep the CLI and CodeQL queries compatible, rather than obtaining the CLI separately and checking out queries independently. Its platform-specific example uses the naming pattern codeql-bundle-PLATFORM.tar.zst. That makes the supported direction clear: change the bundle selection, rather than assembling a replacement toolchain from separate components.

The deadline is mid-March 2027, without an exact day in the announcement. Deprecation begins with CLI 2.27.0; removal follows later. Teams should not interpret the notice as an immediate outage, but download automation that continues requesting the retired package will need attention before removal.

Linux ARM64 makes operating-system selection insufficient​

The immediate exception to the old distribution model is Linux ARM64. GitHub’s September 9 announcement for CodeQL 2.27.0 introduced native execution on Linux ARM64 and explicitly directed users to the linux-arm64 per-platform release assets. The September 22 notice reinforces that these binaries will not enter the all-platform bundle.

The practical implication is straightforward: selecting “Linux” alone is no longer enough for a deployment process serving both x86-64 and ARM64 machines. The download choice must account for the architecture of the machine running CodeQL. A shared Linux installation path that assumes one archive contains every supported architecture needs a more specific selection rule.

GitHub’s supplied system-requirements documentation lists the following host support:

These are CodeQL host requirements, not a statement that every operating system has identical language-analysis capabilities. For example, the same documentation specifies that Swift extraction requires a macOS host.

For Windows administrators, the established architecture boundary is Windows x86-64. Native Linux ARM64 support does not establish Windows ARM64 support. A migration should preserve those platform boundaries rather than treating “ARM64” as a single interchangeable download target across operating systems.

The exact Windows bundle filename is not established by the available release-asset evidence. What is established is the selection requirement: use the platform-specific bundle corresponding to the supported Windows x86-64 host, rather than constructing a filename by analogy with Linux.

CodeQL installation ownership determines who needs to act​

The most directly affected readers are those whose own automation obtains CodeQL. That includes a script downloading a bundle during a build, a runner image containing a preinstalled copy, or an internal distribution process supplying the tool to several environments. Those are operational examples of where the named archive dependency can reside, rather than deployment categories GitHub separately identifies in its notice.

A useful audit starts with the literal filenames codeql-bundle.tar.gz and codeql-bundle.tar.zst. Finding either in an installation script or image definition identifies a concrete place to review. The associated decision is whether that download serves one known host platform or several platforms that will now need separate selection.

An internal mirror can make the dependency less visible. If runners obtain CodeQL through a company-managed artifact location, the relevant change may belong in the process that populates that location rather than in every repository. Administrators should trace which component selects the upstream bundle before deciding where to edit configuration.

GitHub’s September 9 announcement says it automatically deploys new CodeQL versions to GitHub.com code-scanning users. It also says a future GitHub Enterprise Server release will include the new 2.27.0 functionality, with manual CodeQL upgrades available for older GHES versions. These statements do not establish that every repository using code scanning has a manually maintained archive download. The actionable question is who owns CodeQL installation in the affected workflow.

Changing packages also does not remove existing language prerequisites. GitHub’s system requirements specify, for example, that compiled-language extraction on Windows needs PowerShell.exe available on PATH, while Python extraction on Windows needs the Python launcher available as py.exe. Where those requirements apply, replacing the bundle leaves them in place.

The generic CodeQL ZIP has a separate deprecation boundary​

GitHub’s CodeQL 2.27.0 announcement also deprecates the generic multi-platform codeql.zip CLI distribution. Its replacement is a per-platform ZIP, and its removal is described as occurring in a future release. That is related to the bundle transition, but the package names and published timing must remain distinct.

The 2.27.0 announcement also documents a warning when the CLI runs from an all-platform distribution. GitHub provides CODEQL_ALLOW_ALL_PLATFORMS_DIST=true to suppress that warning.

Suppressing a message does not change the selected package or the removal plan. It also cannot supply the Linux ARM64 binaries absent from the combined distribution. Administrators handling noisy build logs should therefore keep warning suppression separate from the work needed to replace the download dependency.

CodeQL administrators should change artifact selection before March​

Prioritize workflows that explicitly fetch an all-platform archive; Linux ARM64 deployments should select their platform-specific package now. For other supported hosts, use the remaining transition period to change the installation path and validate the existing analysis workflow before depending on it in production.

The useful acceptance criterion is that the replacement supports the work the runner already performs. As an operational recommendation, validate the changed installation in a representative nonproduction workflow, including its existing database-creation and analysis stages, rather than treating a successful archive download as the end of the migration.

• Locate references to both codeql-bundle.tar.gz and codeql-bundle.tar.zst in the components that install or distribute CodeQL.
• Select a platform-specific bundle using both the supported host operating system and CPU architecture.
• Use the linux-arm64 platform-specific assets for Linux ARM64 execution; the combined bundle does not contain those binaries.
• Preserve applicable language and build prerequisites when changing the package, including documented Windows executable requirements.
• Schedule the bundle migration before mid-March 2027, and track any separate codeql.zip dependency without assigning it an unannounced removal date.
• Treat the documented warning-suppression variable as a logging control, not as completion of the migration.

GitHub has given existing all-platform bundle users a transition window, while Linux ARM64 already follows the platform-specific model. The concrete outcome should be a CodeQL installation process that explicitly selects the right host package and continues running the established analysis workflow. Completing that change before March removes a scheduled distribution dependency without turning a packaging update into a broader security-tool migration.