CodeQL Scanning Blocked by Xcode 27? 2026 Fix Guide

Symptom: CodeQL scanning stops extracting code after an Xcode or Swift toolchain change.

Fastest fix: For Swift, defer Swift 6.4 and pin the scan to macOS 26 or earlier with Xcode 26 or earlier. For C/C++, C#, and Java, assess build mode: none only after checking coverage; do not treat a started or green workflow as proof of complete analysis.

Who this is for: IT and platform engineering leads responsible for GitHub Actions and CodeQL workflows who need to restore a scan after an environment change.
Security engineers supporting Swift or iOS repositories who need to assess the Swift 6.4 and Xcode 27 boundaries.
Technical leads planning Mac CI capacity who need to decide whether a scan requires a Mac runner.

Last updated October 24, 2026. Compatibility details checked against GitHub’s October 19 CodeQL notice and its current compiled-language CodeQL documentation.

Swift 6.4 scanning

If the affected repository scans Swift, treat compiler success and CodeQL support as separate checks. GitHub states that CodeQL does not support Swift 6.4. A project can therefore build with its selected Xcode while its CodeQL extraction or analysis is unsupported. The GitHub compatibility notice recommends using macOS 26 or earlier and Xcode 26 or earlier for Swift scanning.

That recommendation concerns the scanning environment. It is not a claim that every Mac runner is broken, or that changing the runner alone fixes every CodeQL workflow. Make the smallest controlled change: keep the application build toolchain and the scanning toolchain distinct if your release pipeline needs to test a newer Xcode, but ensure the scan itself runs on the supported combination.

For a team evaluating a Swift 6.4 migration, make the scan-support decision explicit in the upgrade review. If security scanning is a required merge gate, defer the Swift upgrade in that gate until CodeQL support changes or until you have an approved alternative that meets your coverage requirements. Do not approve the migration just because xcodebuild exits successfully.

Important: A green build proves that the build command completed. It does not prove CodeQL extracted the intended Swift source, created a usable database, completed analysis, or uploaded the expected results.

Tracing-based scans with Xcode 27

The Xcode 27 limitation is tied to tracing-based extraction. GitHub’s notice identifies C/C++, C#, Go, Java, Kotlin, and Swift as affected when Xcode 27 is installed. Treat this as a limitation of the extraction route, not a blanket statement that all CodeQL scanning for those languages fails under every configuration.

First identify what the workflow actually does. Read the runner image declaration, the selected Xcode, the CodeQL language configuration, and the build-mode setting together. A workflow may inherit a newer runner image than expected, or select Xcode through a separate setup step. The Xcode 27 runner image release notes help establish what changed in the hosted image, but your workflow logs should confirm what was installed and selected for the particular job.

For Swift or another task that depends on tracing, the official recovery path is to use macOS 26 or earlier and Xcode 26 or earlier. Pin both rather than relying on a moving default image. If you cannot move the whole build pipeline back, route the CodeQL job to a separate supported runner and retain the newer toolchain for the build job where needed.

Do not make a broad language exclusion the first fix. It can hide the error by skipping analysis, while leaving the repository without the security coverage your policy expects. Record any temporary exception, the affected repositories, and the owner who will remove it once a supported scan path is available.

macOS 27 runner diagnosis

The macOS 27 boundary is related to, but not interchangeable with, the Xcode 27 boundary. GitHub says tracing-based extraction may be unavailable on macOS 27. “May be unavailable” is not the same as “every project will fail.” The result depends on the runner image, selected Xcode, language, and CodeQL build mode, so diagnose those inputs before assigning a cause.

Use this order when a scan fails or produces suspiciously incomplete results:

• Confirm the image. Check the workflow’s runner label and the job log. Do not infer the actual OS from the label alone if your organization uses custom or managed images.
• Confirm the selected Xcode. Inspect the setup step and the resolved developer directory. A runner image can contain multiple toolchains, so the image name does not prove which one the job selected.
• Confirm the CodeQL mode. Determine whether the workflow traces a build or uses another mode. The mode affects what extraction expects from the build.
• Compare a pinned rerun. Run the scan on a fixed supported macOS and Xcode combination, then compare extraction and analysis evidence with the affected run.
• Keep the evidence. Save the resolved environment, CodeQL logs, database diagnostics, analysis output, and SARIF upload result alongside the workflow run.

This path avoids two common misdiagnoses: blaming the macOS version when the job actually selected an unsupported Xcode, and blaming Xcode when the workflow was not using tracing-based extraction. If you need a formal change record, store the before-and-after runner and toolchain values with the scan result.

When build mode none is an option

GitHub documents build mode: none as an option to consider for C/C++, C#, and Java. It avoids tracing the build, but it is not automatically equivalent to tracing-based extraction and should not be generalized to every compiled language. Review the compiled-language build options for the applicable language and workflow constraints before changing the mode.

The decision is not simply whether the job turns green. Ask whether the resulting database contains the source and dependency information your repository needs, whether generated code is represented as expected, and whether the analysis results remain credible compared with a known-good scan. GitHub has separate guidance on alerts in generated code; use it when generated files are material to your application or security review.

A mode change needs evidence before it becomes a default. Pick representative repositories, inspect the database and analysis output, and have the security owner review any lost or changed coverage. If the comparison cannot establish adequate coverage, retain the supported tracing environment instead of treating none as a universal workaround.

FAQ: compatibility decisions

Which CodeQL language scans are affected by Xcode 27?

GitHub says tracing-based extraction is unavailable when Xcode 27 is installed for C/C++, C#, Go, Java, Kotlin, and Swift. This is a limitation of that extraction mode, not proof that every workflow on every macOS runner fails. Check the actual runner image and CodeQL build mode before changing the workflow.

Why can’t CodeQL analyze Swift 6.4?

GitHub’s compatibility notice states that CodeQL does not support Swift 6.4. A successful Xcode build does not establish that CodeQL can extract and analyze the source. For Swift scanning, keep the workflow on a supported combination of macOS 26 or earlier and Xcode 26 or earlier, and defer the Swift 6.4 upgrade until support changes.

How should I pin macOS and Xcode for CodeQL scanning?

Pin the runner image explicitly, select the intended Xcode version in the workflow, and record both values with the scan logs. Then rerun CodeQL on the pinned environment and check extraction, database creation, analysis, and SARIF upload separately. A successful job status alone does not prove that the expected source was analyzed.

Can build mode none replace a tracing-based CodeQL build?

Not automatically. GitHub lists build mode none as an option to consider for C/C++, C#, and Java, but it does not promise equivalent coverage to tracing. Compare the database contents and findings with a known-good scan, paying particular attention to generated code and dependency information before approving the mode for a repository.

Intel Mac planning

Intel Mac support is a separate planning item. GitHub says CodeQL support for Intel Macs is planned for deprecation in mid-December 2026, as stated in its compatibility announcement. This is not a workaround for the Xcode 27 tracing limitation, and it does not explain a Swift 6.4 compatibility failure.

Use the deprecation notice to create an inventory, not to make an unverified assumption about which jobs are affected. For each scan workflow, record whether its runner is Intel or Apple Silicon, which repositories it serves, who owns the migration, and what replacement environment needs validation. Then check the current GitHub documentation again before scheduling the change, especially as the stated deprecation period approaches.

Recovery checks for a CodeQL workflow

Use this checklist before restoring a failed scan to a required status check:

• [ ] Identify the repository’s scanned languages and the CodeQL workflow that analyzes them.
• [ ] Record the actual runner image, macOS version, selected Xcode, and Mac architecture from the job environment.
• [ ] Confirm whether the affected language uses tracing-based extraction or build mode: none.
• [ ] For Swift, defer Swift 6.4 and pin the scan to macOS 26 or earlier with Xcode 26 or earlier.
• [ ] For C/C++, C#, or Java, evaluate build mode: none against the repository’s coverage needs instead of switching without review.
• [ ] Rerun the scan on the intended environment and inspect extraction and database-creation logs.
• [ ] Confirm analysis completed and review the results for unexpected gaps or changes.
• [ ] Verify that SARIF was uploaded to the intended repository and category. Follow GitHub’s SARIF upload guidance.
• [ ] Preserve the workflow run and evidence so reviewers can distinguish a completed analysis from a merely successful job.

The GitHub documentation for compiled-language analysis describes the role of build modes in CodeQL extraction. Use the logs and uploaded results to verify that your workflow followed the expected path; a passing CI status alone is not an acceptance test for scan completeness.

Choosing a recovery path

Use the options below to decide what to change first. The table is a decision aid, not a claim that one mode provides identical coverage in every repository.

Once you know whether the scan genuinely requires a Mac runner, decide how to host that workload. If your team already has suitable hardware and can maintain a pinned image, a self-managed Mac may fit. If the workload is temporary or your current capacity cannot provide a supported scanning environment, compare remote Mac hosting with the operational requirements, access controls, and data-handling rules your organization can verify. Do not select a host on the assumption that it fixes CodeQL compatibility by itself.

For that infrastructure review, use the enterprise Mac CI use-case overview to frame the hosting question, and check the current Mac rental plans only after confirming the required environment and terms. Neither page substitutes for validating your exact CodeQL, macOS, and Xcode combination; this guide makes no claim of a tested KVMFLUX configuration for that workload.

Before changing procurement or runner ownership, route one representative repository through the recovery checklist and retain the scan evidence. If the scan must run on a Mac and your existing host cannot provide a supportable, maintainable environment, a remote Mac may be worth evaluating for a temporary or capacity-constrained CI need. If you have a stable, heavy workload that needs dedicated physical capacity or specific local hardware interfaces, compare self-owned hardware as well rather than assuming rental is the right long-term choice.

FAQ