Image: GitHub
Why it mattersA team that runs CodeQL on Swift or on a traced build has to pin its runner image and toolchain to macOS 26 and Xcode 26 before touching the newer versions, or the scan will stop.
Anyone who runs CodeQL on Swift, or on a C/C++, C#, Go, Java or Kotlin project that uses a traced build, has a job to do before anyone on their team installs Xcode 27 or macOS 27. GitHub posted a short changelog this morning saying its code-scanning tool loses traced extraction on both of those versions, cannot analyse Swift 6.4 at all, and will drop Intel-based Macs in mid-December. The entry was marked "Retired" the moment it went live.
The reason is a change on Apple's side. Starting with macOS 27 and Xcode 27, Apple no longer ships Intel x86_64 code in some of the system binaries and libraries that CodeQL uses to attach to a build as it runs. Without that code, CodeQL cannot observe the compiler the way it needs to, which is how it collects the information it reasons from.
What is affected
The changelog names three groups. On Xcode 27, traced extraction is not available for C/C++, C#, Go, Java, Kotlin or Swift. On macOS 27, traced extraction may not be available for the same six languages. Swift 6.4 is unsupported on every platform. CodeQL support for Intel-based Macs will be deprecated in mid-December 2026.
The entry does not list any Apple Silicon-only workaround for Swift 6.4. GitHub names the three categories separately, so pinning Xcode will not help a Swift 6.4 project on its own, because the block is at the language version. The guidance in the next section is to pin to Xcode 26 or earlier for anyone who scans Swift at all.
How to keep scans running
The changelog gives two mitigations. First, pin workflows to macOS 26 or earlier and Xcode 26 or earlier. For teams on GitHub Actions, that means pinning the runner image and the toolchain in the workflow rather than using the latest tags. GitHub names this as the correct answer for anyone who scans Swift at all, and for any traced build on the other five languages.
Second, for C/C++, C# and Java, there is build mode none. That path does not need CodeQL to trace a build at all. GitHub lists it as an alternative to pinning for those three languages, but Go, Kotlin and Swift are not on that list.
A team already on macOS 27 or Xcode 27 may already have scans failing or returning partial results. The entry's wording for macOS 27 ("may not be available") is softer than for Xcode 27 ("isn't available"), which reads as the Xcode installation being the harder constraint. GitHub points to its community discussion for the rest.
The December deadline
The Intel Mac deprecation is a separate deadline on the same page. Any team still running CodeQL on an Intel Mac, as a hosted runner or in a self-hosted setup, has until mid-December 2026 before support ends. The changelog does not list a replacement path for an Intel-only shop, which means moving to Apple Silicon or to a hosted non-Mac runner is the real work the one-line note points to.
The pattern across the three items is the same. CodeQL's build tracing depends on reading Apple's own build environment, Apple is removing the Intel pieces of that environment, and GitHub is matching Apple's calendar. A scan that stops working because the runner image updated on its own produces no error on a pull request, so the main branch can keep merging for weeks before anyone notices the gap in coverage.
Source
CodeQL changes for macOS 27, Xcode 27, and Swift 6.4, GitHub Changelog.
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
