CodeQL changes for macOS 27, Xcode 27, and Swift 6.4

[coadaflorin]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Code scanning

Discussion Details

Starting with macOS 27 and Xcode 27, Apple no longer includes Intel (x86_64) code in some of the system binaries and libraries that CodeQL relies on to trace builds. As a result, CodeQL can't support traced scans on these versions or analyze Swift 6.4.

What's affected

• Xcode 27: When Xcode 27 is installed, traced extraction isn't available for C/C++, C#, Go, Java, Kotlin, or Swift.
• macOS 27: Traced extraction may not be available for the previously mentioned languages.
• Swift 6.4: CodeQL doesn't support Swift 6.4 on any platform.
• Intel-based Macs: CodeQL support for Intel-based Macs will be deprecated in mid-December 2026.

How to keep your scans running

If you scan Swift or use traced builds for other languages, pin your workflows to macOS 26 or earlier and Xcode 26 or earlier. If you use GitHub Actions, pin the runner image and toolchain in your workflow rather than relying on the latest versions.

For C/C++, C#, and Java, you can switch to build mode none, which doesn't require tracing a build.

[yadhavkrishnasb]

Why This Is Happening CodeQL’s traditional autobuild and manual build modes rely on traced extraction. During compilation, a native tracer injects into compiler process calls to capture source files and AST representations. Starting with macOS 27 and Xcode 27, Apple stripped legacy universal x86_64 architecture code from several core system binaries and developer libraries. Because parts of CodeQL's macOS tracing wrapper depended on hooks into those Intel/universal binaries, CodeQL can no longer attach to compiler invocations when Xcode 27 is installed. Key Failure Points & The "Silent Zero" RiskFloating runs-on: macos-latest: If your GitHub Actions workflow uses a floating tag, an image update to Xcode 27 or macOS 27 will break traced compilation for C/C++, C#, Go, Java, Kotlin, and Swift without warning. Silent False Negatives on Swift 6.4: Teams running Swift 6.4 have noted runs returning exit code 0 with zero detected alerts, while the SARIF logs contain extraction errors. CodeQL may exit cleanly even though 0% of the Swift codebase was actually scanned. Intel Mac Runners Deprecation: Self-hosted Intel (x86_64) Mac runners will reach end-of-support in mid-December 2026. Practical Fixes for GitHub Actions1. Pin Your Runner Image and Xcode Version (For Swift, Go, Kotlin)Because Swift, Go, and Kotlin do not have a build-mode: none option in CodeQL, the only current path is to explicitly lock your runner and Xcode version:YAMLjobs:
analyze:
# Pin to macOS 26 instead of macos-latest
runs-on: macos-26

steps:
  - name: Checkout repository
    uses: actions/checkout@v4

  # Explicitly select an Xcode 26.x toolchain
  - name: Select Xcode 26
    run: sudo xcode-select -s /Applications/Xcode_26.app/Contents/Developer

  - name: Initialize CodeQL
    uses: github/codeql-action/init@v3
    with:
      languages: swift

  - name: Perform CodeQL Analysis
    uses: github/codeql-action/analyze@v3

2. Switch to build-mode: none (For C/C++, C#, and Java)If you are running CI on macOS for C/C++, C#, or Java, bypass traced extraction entirely by using build-mode: none. In this mode, CodeQL reads and extracts files directly without intercepting the build compiler: YAML- name: Initialize CodeQL
   uses: github/codeql-action/init@v3
   with:
   languages: c-cpp # or csharp, java-kotlin
   build-mode: none
3. Decouple Production Builds from Security ScansIf an app requires Xcode 27 SDK features (e.g., App Store submissions requiring new toolchains): Job A (Release Build): Run on macos-latest / Xcode 27 to compile, package, and sign release binaries. Job B (CodeQL Scan): Run as a separate matrix job pinned to macos-26 / Xcode 26 solely for vulnerability scanning (provided your source code does not yet use language features exclusive to Swift 6.4).

[coadaflorin]

"Silent zero" scans returning no alerts while exiting successfully.

@yadhavkrishnasb can you please share a reproducible scenario for this case? In our testing we have not seen scans completing successfully when Swift 6.4 was used.

[yadhavkrishnasb]

Hi @coadaflorin, thanks for looking into this.

Here is a minimal reproducible scenario that demonstrates the "silent zero" behavior. The core issue seems to be that when the tracing wrapper fails to attach to the swiftc compiler process under Xcode 27, CodeQL fails to extract the files but still finalizes an empty database. Because the database is technically valid (just empty), the analyze step exits with code 0 and reports 0 vulnerabilities, missing blatant issues.

Reproducible Scenario

1. Vulnerable Swift Code (Sources/main.swift)
   This includes a blatant hardcoded password (CWE-798) that CodeQL normally catches instantly.

Swift
import Foundation

func authenticate() {
// This should trigger a CodeQL alert for hardcoded credentials
let dbPassword = "super_secret_hardcoded_password_123!"
print("Connecting with password: (dbPassword)")
}

authenticate()
2. Package Manifest (Package.swift)

Swift
// swift-tools-version: 6.4
import PackageDescription

let package = Package(
name: "CodeQLSilentZeroRepro",
targets: [
.executableTarget(
name: "CodeQLSilentZeroRepro",
path: "Sources"
)
]
)
3. GitHub Actions Workflow (.github/workflows/codeql-repro.yml)
This forces the runner to use the macOS 27 / Xcode 27 environment.

YAML
name: "CodeQL Swift 6.4 Silent Zero Repro"

on:
push:
branches: [ "main" ]
workflow_dispatch:

jobs:
analyze:
name: Analyze
runs-on: macos-latest # Pulls macOS 27

steps:
- name: Checkout repository
  uses: actions/checkout@v4

- name: Select Xcode 27 (Swift 6.4)
  run: sudo xcode-select -s /Applications/Xcode_27.app/Contents/Developer
  
- name: Initialize CodeQL
  uses: github/codeql-action/init@v3
  with:
    languages: swift

- name: Build Swift project
  run: swift build

- name: Perform CodeQL Analysis
  uses: github/codeql-action/analyze@v3
  with:
    category: "/language:swift"

[jketema]

Hi @yadhavkrishnasb,

I had to modify your workflow slightly when trying this out:

name: "CodeQL Swift 6.4 Silent Zero Repro"

on:
  push:
    branches: [ "main" ]
  workflow_dispatch:

jobs:
  analyze:
    name: Analyze
    runs-on: xcode-27 # macos-latest runners are currently macOS 26 runners without Xocde 27 installed

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    # Xcode 27 is selected by default on xcode-27 runners
    # - name: Select Xcode 27 (Swift 6.4)
    #   run: sudo xcode-select -s /Applications/Xcode_27.app/Contents/Developer

    - name: Initialize CodeQL
      uses: github/codeql-action/init@v3
      with:
        languages: swift

    - name: Build Swift project
      run: swift build

    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v3
      with:
        category: "/language:swift"

With the above change, I do not see the silent behavior you're describing, instead I see a failure:

Is there maybe something missing from your reproducer?

[GYSK-KRISH]

If you use CodeQL on macOS, pin your workflows to macOS 26/Xcode 26 for now. Swift 6.4 is unsupported, and C/C++/C#/Java users can consider build-mode: none as a workaround.

[GYSK-KRISH]

• CodeQL traced extraction is affected by macOS 27 and Xcode 27.

• Swift 6.4 is not supported by CodeQL.

• Users should pin to macOS 26/Xcode 26 or earlier.

• For C/C++, C#, and Java, build-mode: none is a supported workaround.

_

Treat with caution

The following claims are not mentioned in the announcement itself:

1. "Silent zero" scans returning no alerts while exiting successfully.
2. Detailed explanation about CodeQL's internal tracing hooks depending on Intel binaries.
3. Specific extraction-error behaviour in SARIF logs.
4. The exact technical reason behind the tracing failure.

These may be informed assumptions or observations from users, but they are not officially confirmed in the GitHub post.

[coadaflorin]

"Silent zero" scans returning no alerts while exiting successfully.

@GYSK-KRISH can you please share a reproducible scenario for this case? In our testing we have not seen scans completing successfully when Swift 6.4 was used.

[njarecha]

Are there any plans to support CodeQL on macOS 27, Xcode 27, and Swift 6.4 in the future?

[coadaflorin]

To add to @jketema's note, we are also working on improving our Swift analysis and we plan to be able to scan Swift 6.4 with CodeQL next year.

[njarecha]

Thank you!

[chri7325]

@coadaflorin do you happen to know if build-mode: manual will eventually be supported down the line? With Apple phasing out intel and rosetta starting in macOS 28, will codeql be able to use the arm64 variants of the tracers?

[jketema]

@chri7325 No. Tracing requires us to see which processes are created, and Apple's only supported ways of seeing this are through DTrace and its Endpoint Security API.

DTrace requires System Integrity Protection (SIP) to be (partially) disabled, which we cannot assume to be the case. The Endpoint Security API requires root access and a special signing certificate from Apple. Although we might be able to obtain the certificate, we cannot assume that root access is available.

For Intel binaries and Universal binaries we could work around this by using the x86 slices of system binaries and resigning those. Hence, the need to Rosetta. For system binaries with only a arm slice (technically arm64e slice), we cannot do this, as Apple does not allow resigning of those.

[chri7325]

@jketema I see. Thank you for the detailed explanation of this. It is unfortunate that Apple is aggressively phasing out intel without providing all feature replacements but I guess that is just the nature of the beast.

[NexzaDev]

Thanks for posting this. Since the post lists several separate changes, here's a practical checklist for working out whether you're affected and what to change.

1. What is and isn't affected

• Swift: needs the pinned toolchain (Xcode 26.x or earlier). CodeQL doesn't support Swift 6.4 on any platform, so there is no build-mode workaround for Swift.
• C/C++, C#, Java (traced builds): these are affected when Xcode 27 is installed. Switching to build mode none avoids the tracing dependency.
• Go and Kotlin: per the CodeQL docs, none isn't available for these (only autobuild and manual), so for traced extraction on macOS they need the pinned environment.
• Intel-based Macs: CodeQL support is deprecated from mid-December 2026, so any job on an Intel runner needs a migration plan.

2. Pin the runner and Xcode explicitly (Swift and other traced builds)

Don't rely on macos-latest. Per GitHub's runner-images announcements, that label was moving to macos-26, and Xcode 27 is available on the images as a public preview, so a job that selects "latest" tooling could pick up a version CodeQL can't trace. Pin both the runner and the Xcode version:

jobs:
  analyze:
    runs-on: macos-26            # Apple silicon image; use macos-26-intel only if you must
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode 26.6
        run: sudo xcode-select -s /Applications/Xcode_26.6.app
      - uses: github/codeql-action/init@v3   # keep whichever version you already use
        with:
          languages: swift
          build-mode: autobuild
      - uses: github/codeql-action/analyze@v3

Check the "Set up job" log of a recent run to confirm which image version and Xcode were actually used, and compare it against the runner-images release notes.

3. Switch to build mode none where it's supported

The docs list none as supported for C/C++, C# and Java. With a language matrix you can set it per language:

strategy:
  matrix:
    include:
      - language: c-cpp
        build-mode: none
      - language: csharp
        build-mode: none
      - language: java-kotlin
        build-mode: none     # analyzes Java only
      - language: swift
        build-mode: autobuild
steps:
  - uses: github/codeql-action/init@v3
    with:
      languages: ${{ matrix.language }}
      build-mode: ${{ matrix.build-mode }}

Trade-offs to be aware of:

• For C/C++, the docs warn that analysis without a build can be less accurate than autobuild or manual builds in some cases, so compare the alerts before and after on one repository first.
• For C#, none needs access to the public internet or to your private NuGet feed to resolve dependencies.
• For java-kotlin, none analyzes only the Java part.

4. Intel runners

If you use macos-26-intel or self-hosted Intel Macs for CodeQL, plan to move those jobs to Apple silicon before mid-December 2026.

5. Rollout suggestion

1. Search your organization for workflows that run CodeQL on macOS (runs-on: macos-*) and list the languages each one scans.
2. Change one repository per language to the pinned or none configuration, then check that code scanning results still look comparable.
3. Roll the change out, and set a reminder to revisit the pins once CodeQL announces support for the newer toolchains, so you don't stay on old images longer than needed.

Hope this helps anyone planning the migration.