GitHub CodeQL Traced Scans Break on macOS 27 and Xcode 27: CI Pinning Guide

What GitHub says is affected​

GitHub's notice, published on October 19, 2026, breaks the impact down by component:

• Xcode 27: When Xcode 27 is installed, traced extraction isn't available for C/C++, C#, Go, Java, Kotlin, or Swift. The notice ties this to Xcode 27 being installed. It doesn't limit it to macOS 27.
• macOS 27: Traced extraction may not be available for the same languages. The wording is conditional, so treat it as a strong warning and not a guaranteed failure in every setup.
• Swift 6.4: CodeQL doesn't support Swift 6.4 on any platform. This is a wider limit than the tracing problem. Swift 6.4 is out of reach even if you solve the tracer issue.
• Intel-based Macs: CodeQL support for Intel-based Macs will be deprecated in mid-December 2026. GitHub gives no exact day.

"Traced extraction" is the mode where CodeQL watches your real build and records what the compiler sees. It is used for autobuild and manual build modes. The notice says tracing is unavailable. It doesn't say every possible CodeQL scan of these languages is impossible.

Earlier warning in CodeQL 2.27.2​

This isn't entirely new. GitHub's October 9 release notes for CodeQL 2.27.2 flagged the same problem. They said Apple stopped shipping multi-architecture x86-64/arm64 binaries, and that autobuild and manual modes for compiled languages won't be supported on macOS 27 with any Xcode version. They also won't be supported on macOS 26 when Xcode 27 is selected. GitHub added that it is working on better support for build mode none on macOS to ease the limitation.

That second condition matters. Upgrading only Xcode on a macOS 26 runner is enough to hit the problem.

How to keep scans running​

GitHub's guidance has two parts:

1. Pin the environment. If you scan Swift or use traced builds for other languages, pin your workflows to macOS 26 or earlier and Xcode 26 or earlier. In GitHub Actions, pin the runner image and toolchain rather than relying on the latest versions.
2. Consider build mode none where it exists. For C/C++, C#, and Java, you can switch to build mode none, which doesn't require tracing a build.

GitHub's documentation lists the build modes per language:

Go, Kotlin and Swift have no none option in the current docs, and the notice doesn't offer one for them. Those projects can only pin to older tooling for now.

Build mode none is not a free swap​

Switching to none changes how accurate the results are. For C/C++, the docs say a database built without a build can be less accurate in some cases. Examples are code that relies heavily on custom macros or defines, or code with many external dependencies. For C# and Java, results depend on restoring or querying dependencies. Java accuracy can also suffer if the repository normally generates code during the build.

The docs suggest ways to improve accuracy:

• C#: give the scan internet access or a reachable private NuGet feed, and watch for multiple versions of the same dependency or of .NET.
• Java: allow access to a private artifact repository where needed, and avoid colliding class names.
• C/C++: keep custom macros in headers and make sure external headers are in system include directories or the workspace.

After switching, compare alert counts and coverage against a known-good traced run. A scan that finishes without findings isn't necessarily a good scan.

What teams are seeing​

Public repositories show the failure in practice, though these are individual reports and not GitHub statements.

• One project reported that its traced Swift build on a macOS 27, Xcode 27.1 runner failed with a "Bad CPU type in executable" error on /usr/bin/sandbox-exec.
• Another reported that a local scan on Xcode 27.0 with Swift 6.4 returned exit code zero and no findings. Its SARIF output still held 737 compiler-error notifications, so the clean result wasn't a valid scan. This is a useful warning about silent false negatives.
• Several projects have paused their Swift CodeQL jobs. They can't pin to Xcode 26 because their apps now need the iOS 27 or macOS 27 SDKs. They have been tracking the issue in an open CodeQL repository thread with no ETA.

Who should act now​

Pin now if you:

• run Swift or Apple-platform code scanning
• use runs-on labels that float to the newest macOS image
• select Xcode with a "latest" selector
• run self-hosted Mac runners that might be upgraded

Weigh the tradeoffs if you:

• must build with the Xcode 27 SDKs but also need security scanning for Swift. Pinning to Xcode 26 may conflict with your SDK requirements. GitHub offers no workaround and no firm date for restored support in that case.
• run Intel Macs. Support deprecation arrives in mid-December 2026, so plan a move to Apple silicon runners.

Practical checklist​

1. Find every CodeQL workflow that touches macOS runners or Xcode.
2. Pin the runner image and the Xcode version explicitly.
3. For C/C++, C#, and Java, decide whether none is acceptable and validate its results.
4. For Swift, Go and Kotlin with traced builds, stay on macOS 26 or earlier and Xcode 26 or earlier.
5. Add a check that fails loudly if extraction produces errors or zero files. Don't rely on a clean exit code.
6. Track the GitHub Community discussion and the CodeQL repository for updates.

Analysis​

This is a platform-vendor side effect, not a CodeQL bug. A tracer that wraps system binaries is exposed when Apple changes what those binaries contain. Apple's move away from Intel code is consistent with its wider shift to Apple silicon. For security teams, the point is that toolchain upgrades can silently reduce scanning coverage, and that is a risk to manage in CI.

GitHub hasn't announced a timeline for fixing this. Pinning is a stopgap. It gets harder the longer your application targets the new SDKs.