Description

sjmadsen

opened on Jan 22, 2026

Issue body actions

I'm trying to integrate CodeQL in a private repo, using a self-hosted runner. My first attempt failed with this error:

node:internal/child_process:420
    throw new ErrnoException(err, 'spawn');
    ^

Error: spawn Unknown system error -86
    at ChildProcess.spawn (node:internal/child_process:420:11)
    at spawn (node:child_process:762:9)
    at Object.<anonymous> (/Users/admin/Code/ActionRunner/bin.2.331.0/macos-run-invoker.js:8:14)
    at Module._compile (node:internal/modules/cjs/loader:1521:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1623:10)
    at Module.load (node:internal/modules/cjs/loader:1266:32)
    at Module._load (node:internal/modules/cjs/loader:1091:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:164:12)
    at node:internal/main/run_main_module:28:49 {
  errno: -86,
  code: 'Unknown system error -86',
  syscall: 'spawn'
}

I've managed to work around this by installed Rosetta on the build machine, but that's a temporary workaround, since Rosetta is going away in the next year or two.

I still hit something that I suspect is an architecture mismatch, though. Most of the targets in the Xcode project use the SwiftLint build tool plug-in, and when xcodebuild gets to that step, it fails with this error:

SourceKittenFramework/library_wrapper.swift:58: Fatal error: Loading sourcekitdInProc.framework/Versions/A/sourcekitdInProc failed

My best guess is that sourcekitdInProc is an arm64 binary, while part of CodeQL still uses an x86 binary.

I've also tried running this on GitHub's shared macOS runners, but they are abysmally slow and I'd need to work out an authentication issue with a dependency in a different private repo. It'd be much nicer to get this working on the self-hosted runner.

Reacted by Jozef Izso

Activity

1. mbg commented on Jan 22, 2026

   

   mbg

   on Jan 22, 2026

   Member

   More actions

   Hi @sjmadsen 👋🏻

   I've managed to work around this by installed Rosetta on the build machine, but that's a temporary workaround, since Rosetta is going away in the next year or two.

   Rosetta is currently required for CodeQL.

   I still hit something that I suspect is an architecture mismatch, though. Most of the targets in the Xcode project use the SwiftLint build tool plug-in, and when xcodebuild gets to that step, it fails with this error:

   That's plausible. Since this is for a private repo, I'd suggest reaching out to our customer support. This would allow you to share extra information about your setup, logs, etc. privately, which our engineering team that looks after Swift may need to troubleshoot this further.

   Reacted by Steve Madsen
2. jozefizso commented on Jul 13, 2026

   

   jozefizso

   on Jul 13, 2026

   More actions

   Hi @mbg, when will CodeQL support native analysis?

   Beside the same problem with the SwiftLint, the analysis running on Rosetta takes 45 minutes. That's unacceptable when our full production workflow takes just 5 minutes to finish on this project.
3. sjmadsen commented on Jul 13, 2026

   

   sjmadsen

   on Jul 13, 2026

   Author

   More actions

   I filed a customer support issue on this back in January. We had a good back-and-forth for a couple of weeks as they tried to diagnose and fix the problem, but it's been radio silence for months now.
4. coadaflorin commented on Jul 14, 2026

   

   coadaflorin

   on Jul 14, 2026

   Contributor

   More actions

   Hey 👋 Florin from the CodeQL product team.

   We are currently working on improving our Swift support on Mac runners. As a lot of this work is still research I can not provide a perfect timeline right now, but keep an eye on the roadmap over the coming quarters.

Issue actions