CodeQL Swift Scanning Has No Supported Setup on Xcode 27. Some Runs Still Pass.

The CodeQL 2.27.2 release notes, posted on 9 October, carry a section most readers will scroll past. Apple stopped shipping combined x86-64 and arm64 binaries with macOS 27 and Xcode 27, and CodeQL's traced analysis depends on them. So autobuild and manual build modes are unsupported for compiled languages on macOS 27 with any Xcode, and on macOS 26 once Xcode 27 is selected. GitHub's advice is to stay on macOS 26 and Xcode 26, and it says it is improving build mode none on macOS.

For CodeQL Swift scanning, that advice has a gap the notes do not mention.

CodeQL Swift has no build mode left on Xcode 27

GitHub's own reference page on build options lists exactly two build modes for Swift: autobuild and manual. There is no none. The CodeQL supported-platforms page, updated in a pull request merged on 9 October, now says macOS 27 support is limited to Apple Silicon with build mode none, and macOS 26 with Xcode 27 is limited to the same. Put the two pages side by side and Swift has no supported configuration on either platform. The supported-compilers table in the CodeQL repository tops out at Swift 6.3.

A GitHub product team member said the same thing more bluntly on 2 October, in reply to a bug report. Swift 6.4 ships with Xcode 27, GitHub cannot support it, the only workaround for Swift 6.3 and earlier is a machine on macOS 26 or older with Xcode 26 or older, and a new cross-platform Swift scanner is in progress. No date was given. A team that adopts anything requiring the Swift 6.4 toolchain therefore has no CodeQL path at all until that scanner exists.

The pattern: an unsupported scan is not a failing scan

This is the second September running that an Xcode major has outpaced CodeQL Swift, and the second time since June that a moving macOS label has broken a Swift scan.

In September 2025 a user reported that Swift analysis failed with Xcode 26.0. A maintainer replied that release candidates are not supported, and the fix eventually landed in CodeQL 2.23.5, announced in the thread on 13 November. That is roughly two months of broken scans for anyone who moved early. In June 2026 the CodeQL Action's own Swift checks went red when the macos-latest-xlarge label began resolving to macOS 26, which no longer carried Xcode 16; the maintainers pinned that job to macOS 15.

Both of those failed loudly. This year's break does not reliably do so, and that is the part worth acting on.

The runner-images team opened the xcode-27 label as a public preview on 16 July and, in an edit dated 16 September, moved it onto a macOS 27 base. Its readme lists macOS 27.0.1 with Xcode 27.0 as the default. That label satisfies both unsupported conditions at once. GitHub code search returns 47 public workflow files that mention both xcode-27 and codeql-action.

Two of them ran this month with opposite outcomes. CotEditor's CodeQL job on the xcode-27-arm64 image failed on 2 October while building its Swift packages, with a posix_spawn Bad CPU type error. That is the same symptom the independent bug report describes for the macro plugin host under the tracer. Monolingual's Swift job on the same image, using CodeQL 2.27.2 with a manual build on 10 October, printed BUILD SUCCEEDED, finalized a database, evaluated 29 queries and finished green. The Swift job carried no annotations at all.

We could not check whether Monolingual's database is complete. The run log prints no file count, and the code scanning analyses API refused our request with a 403, as it does for anyone without access to the repository's alerts. That is exactly the problem. A green check on a setup the vendor calls unsupported tells you the run ended, not that the code was analyzed. As we argued in the gap between a PoC and production, silent degradation is the default failure mode, and a security scanner is no exception. The same shape showed up when node20 actions kept passing after Node 20 left the runners.

The guard is still a pull request

GitHub has a fix in progress. Pull request 4221 in the CodeQL Action, opened on 9 October and still open, checks the macOS and Xcode versions whenever Swift is being analyzed. As written, it reports a warning. Aborting the analysis sits behind a feature flag, swift_skip_unsupported_traced_analysis, whose default in the code is off. Until it ships, the xcode-27 runs above get no warning at all.

The larger exposure is the starter template. GitHub's CodeQL starter workflow routes the Swift matrix entry to macos-latest, and code search matches that routing line in 21,152 public workflow files. That counts files carrying the template, not repositories that analyze Swift. Last year, macos-26 went to preview in September 2025, became generally available in February 2026 and took over macos-latest between 15 June and 15 July 2026. If macOS 27 follows the same path, every Swift scan built from that template lands on an unsupported runner next summer, whether or not the scanner is ready.

The claim here is falsifiable. Today, every green CodeQL Swift job on the xcode-27 label runs a configuration GitHub's own documentation calls unsupported, and nothing in the run says so. A CodeQL release that adds Swift support for Xcode 27, or a CodeQL Action release that fails such runs by default, would make this wrong.

The cheapest way out

1. Find the exposed workflows. Replace your-org and run:

gh api -X GET search/code -f q='org:your-org xcode-27 codeql-action path:.github/workflows' --jq '.items[]|[.repository.full_name,.path]|@tsv'

1. For any green Swift scan, confirm which image actually ran it:

gh run view <run-id> --repo <owner/repo> --log | grep 'Analyze (swift)' | grep -m1 'Image: '

An xcode-27-arm64 result means the scan ran on an unsupported setup.

1. Pin the Swift CodeQL job, and only that job, to macos-26 with an Xcode 26 toolchain selected. Leave the app's real build on xcode-27 if you need it. Replace macos-latest in the template's Swift routing with macos-26 now, rather than finding out when the label moves.
2. Do not adopt Swift 6.4-only language features in code you need scanned until GitHub ships the new Swift scanner. Write that down as a decision.