Azure DevOps CodeQL init causes SwiftPM unableToFind(tool: "clang") with Xcode 26.3

No source confirms Xcode 26.3 as supported with the CodeQL bundle currently installed on the hosted agent, so update the Azure DevOps CodeQL task to obtain the latest bundle and, if the failure remains, collect the tracer database logs for Microsoft support rather than modifying the copied Xcode toolchain.

Use the latest CodeQL bundle

Swift is supported by GitHub Advanced Security for Azure DevOps, and Manual is the correct build mode: Swift does not support build mode None.^1^

However, that general Swift support does not establish compatibility with every Xcode release. In particular, CodeQL CLI 2.23.3 was explicitly reported as not supporting Xcode 26.^2^ Your log must identify the actual bundle version before support for 26.3 can be determined.

In the Classic pipeline:

1. Open Advanced Security Initialize CodeQL.
2. Keep:
   • Languages: swift
   • Build mode: Manual
3. Select Enable automatic CodeQL detection and installation.
4. Set Log level to Debug (2).
5. Queue a clean run and record the CodeQL CLI/bundle version printed by initialization.

The initialization task documents both enableAutomaticCodeQLInstall, which installs the latest version when the existing installation is absent or outdated, and debug logging through loglevel: 2.^3^

Keep the required order:

1. CodeQL initialization
2. xcodebuild archive or the Xcode task
3. CodeQL analysis

Your pre-initialization dependency-resolution step may remain, but the traced archive is still allowed to resolve its package graph. The compiled build that CodeQL analyzes must occur between initialization and analysis.^4^

Diagnose the lookup under the tracer

The matching Developer Community report describes the same failure pattern: CodeQL relocates/intercepts swiftc, SwiftPM derives a toolchain location from that compiler, and sibling clang lookup then fails in the copy root.^5^ Your observations are consistent with that mechanism, but the missing copy-root clang entry alone does not prove it; the tracer log is needed.

Add an Agent job → Command line task after the archive with Run this task: Even if a previous task has failed, using:

set -u
echo "CodeQL-related environment:"
env | sort | grep -E '^(SEMMLE|CODEQL|DEVELOPER_DIR|TOOLCHAINS)=' || true

echo "Compiler resolution:"
xcrun --find swiftc || true
xcrun --find clang || true

echo "Tracer and database logs:"
find "$AGENT_TEMPDIRECTORY" -type f \
  \( -name 'build-tracer.log' -o -name '*.log' \) \
  -path '*advancedsecurity.codeql*' -print 2>/dev/null || true

Do not dump complete environment values or source/database contents into public logs. CodeQL diagnostic artifacts can contain sensitive information, including analyzed source content.

For the run itself, set the Classic pipeline variable system.debug to true. Azure Pipelines documents this as the switch for verbose task and agent diagnostics.^6^

Upload the located build-tracer.log as a secure pipeline artifact or support attachment. Azure Pipelines supports uploading individual custom logs with ##vso[task.uploadfile] or directories with PublishPipelineArtifact@1.^6^

Supported remediation and escalation

If the newest automatically installed bundle still fails:

• Do not create clang or SDK-header symlinks in SEMMLE_COPY_EXECUTABLES_ROOT; your Darwin-module failure shows that this creates an incomplete relocated toolchain rather than a supported repair.
• Do not repeat the SwiftPM cache or cloned-package-directory changes; those have already ruled out package-cache state.
• If operationally possible, use an older Xcode version that is supported by the installed CodeQL bundle as a temporary workaround. This is a compatibility isolation step, not evidence that Xcode itself is defective.
• Open a Microsoft Azure DevOps support case and attach:
  • pipeline run URL and hosted image;
  • Xcode version/build;
  • CodeQL CLI/bundle and task versions;
  • system.debug logs;
  • build-tracer.log;
  • the pre-/post-init compiler paths and copy-root listing;
  • confirmation that the identical archive succeeds without CodeQL.

The exact Xcode 26.3 Azure Pipelines report was closed upstream because the Azure DevOps integration is maintained by Microsoft rather than by github/codeql-action.[^7^](https://github.com/github/codeql-action/issues/4279 "#4279 Azure Pipelines: Xcode 26.3 fails to resolve SwiftPM dependencies with unableToFind(tool: "clang") after CodeQL initialization")

References

1. Set up code scanning
2. Xcode 26 support? · Issue #20669 · github/codeql
3. AdvancedSecurity-Codeql-Init@1 - Advanced Security Initialize CodeQL v1 ...
4. Troubleshoot code scanning for GitHub Advanced Security for Azure ...
5. CodeQL (Advanced Security) Swift build tracing fails with unableToFind ...
6. Review logs to diagnose pipeline issues
7. #4279 Azure Pipelines: Xcode 26.3 fails to resolve SwiftPM dependencies with unableToFind(tool: "clang") after CodeQL initialization