Observed
The source-build fallback in scripts/download-prebuilt-ghosttykit.sh cannot build on the CI runners. When it runs, it fails while linking zig's own build runner, not our code:
error: undefined symbol: __availability_version_check
note: referenced by /Users/runner/.cache/zig/o/.../libcompiler_rt.a(libcompiler_rt_zcu.o):___isPlatformVersionAtLeast
error: undefined symbol: _abort
note: referenced by .zig-cache/o/.../build_zcu.o:_posix.abort
error: undefined symbol: _dispatch_queue_create
note: referenced by .zig-cache/o/.../build_zcu.o:_Build.Watch.FsEvents.init
##[error]Process completed with exit code 2.
Every undefined symbol is libc or libdispatch, and every reference is from build_zcu.o or libcompiler_rt.a — zig's build executable failing to link against libSystem. No ghostty source is reached.
Observed on PR #288, run 31518843810, job 93873265801 (macOS runner, zig 0.15.2). The fallback was reached because of a missing checksum pin (separate issue); the point here is that once reached, it cannot succeed.
Why it matters
The fallback exists so CI can still produce a GhosttyKit when no prebuilt artifact is available. It cannot do that. So the real behavior is: no prebuilt means CI fails, with an error that looks like a compiler bug. Anything relying on it as a safety net is relying on something that has never worked on these runners.
There is a local signal pointing the same way: reload.sh prints Auto-enabling PROGRAMA_SKIP_ZIG_BUILD=1 for Ghostty CLI helper (macOS 26.5.2 + zig 0.15.2), i.e. local zig builds are already being routed around on the same toolchain pairing.
Likely cause
zig cannot find the macOS SDK when linking its build runner — no --sysroot / SDKROOT, or a mismatch between the selected Xcode and what zig probes. Note step 8 (Install zig) is skipped when the fallback runs from inside the download script, since the script installs its own zig; that copy may not get the same environment the workflow's zig would.
Fix options
- Give the fallback the SDK explicitly (
SDKROOT=$(xcrun --show-sdk-path), and xcode-select -s globally rather than DEVELOPER_DIR alone — the same shim mismatch that has bitten test jobs before).
- Drop the fallback and fail with a clear message instead. Given a prebuilt is published for every ghostty SHA by the
Build GhosttyKit workflow, a missing artifact is a pipeline bug worth surfacing, not papering over.
Option 2 is less code and less to keep working; option 1 keeps a genuine escape hatch for a ghostty SHA whose build has not published yet.
Verify
Force the fallback (GHOSTTYKIT_CHECKSUMS_FILE=/dev/null) on a CI job. It either produces a usable GhosttyKit.xcframework, or it fails with a message naming the missing prebuilt — but not with undefined libc symbols from zig's build runner.
Observed
The source-build fallback in
scripts/download-prebuilt-ghosttykit.shcannot build on the CI runners. When it runs, it fails while linking zig's own build runner, not our code:Every undefined symbol is libc or libdispatch, and every reference is from
build_zcu.oorlibcompiler_rt.a— zig's build executable failing to link against libSystem. No ghostty source is reached.Observed on PR #288, run 31518843810, job 93873265801 (macOS runner, zig 0.15.2). The fallback was reached because of a missing checksum pin (separate issue); the point here is that once reached, it cannot succeed.
Why it matters
The fallback exists so CI can still produce a GhosttyKit when no prebuilt artifact is available. It cannot do that. So the real behavior is: no prebuilt means CI fails, with an error that looks like a compiler bug. Anything relying on it as a safety net is relying on something that has never worked on these runners.
There is a local signal pointing the same way:
reload.shprintsAuto-enabling PROGRAMA_SKIP_ZIG_BUILD=1 for Ghostty CLI helper (macOS 26.5.2 + zig 0.15.2), i.e. local zig builds are already being routed around on the same toolchain pairing.Likely cause
zig cannot find the macOS SDK when linking its build runner — no
--sysroot/SDKROOT, or a mismatch between the selected Xcode and what zig probes. Note step 8 (Install zig) is skipped when the fallback runs from inside the download script, since the script installs its own zig; that copy may not get the same environment the workflow's zig would.Fix options
SDKROOT=$(xcrun --show-sdk-path), andxcode-select -sglobally rather thanDEVELOPER_DIRalone — the same shim mismatch that has bitten test jobs before).Build GhosttyKitworkflow, a missing artifact is a pipeline bug worth surfacing, not papering over.Option 2 is less code and less to keep working; option 1 keeps a genuine escape hatch for a ghostty SHA whose build has not published yet.
Verify
Force the fallback (
GHOSTTYKIT_CHECKSUMS_FILE=/dev/null) on a CI job. It either produces a usableGhosttyKit.xcframework, or it fails with a message naming the missing prebuilt — but not with undefined libc symbols from zig's build runner.