Copilot CLI linux-arm64 binary: ENOEXEC on Linux 6.12 (aarch64, 4K pages); runs via ld.so #5424

Summary

The @github/copilot linux-arm64 platform binary (@github/copilot-linux-arm64/copilot, a Bun single-file executable) fails execve(2) with ENOEXEC ("Exec format error") on Linux 6.12 aarch64 (4K pages). The identical file runs when started through the dynamic loader: /lib/ld-linux-aarch64.so.1 ./copilot --version → GitHub Copilot CLI 1.0.88. The same binary executed directly without issue on Linux 5.15 the day before.

Observed on Oracle Linux 9.8 / UEK8 6.12.0-207.111.5.6.el9uek.aarch64 (OKE A1.Flex nodes), Debian 13 container image, Node 26. Versions 1.0.88 and 1.0.78 fail identically.

Because the npm bin shim is a shell script, the failure is silent in practice: sh falls back to interpreting the ELF as a script (copilot: 1: : not found, /lib/ld-linux-aarch64.so.1GNU…: not found), so callers see no useful error.

ELF facts

readelf-equivalent of the binary: ELF64, aarch64 (e_machine=0xb7), e_type=ET_EXEC (not PIE), EI_OSABI=3 (GNU/Linux), 11 program headers:

Ruled out: copying to tmpfs still ENOEXEC (not overlayfs); binfmt_misc empty; seccomp 0; no dmesg output; randomize_va_space=2.

Hypothesis: the mixed p_align (0x10000 code/data vs 0x1000 appended segment) on a fixed-address ET_EXEC trips the stricter checks in the 6.12 binfmt_elf elf_load() path, while glibc's ld.so maps the same layout fine. Not pinned down further.

Workaround we deploy

Rename the platform binary to copilot.real and replace copilot with:

#!/bin/sh
exec /lib/ld-linux-aarch64.so.1 /path/to/@github/copilot-linux-arm64/copilot.real "$@"

Ask

• Ship the Linux binaries as PIE / ET_DYN (or otherwise with consistent segment alignment) so they load on 6.12+ kernels, or
• have the npm shim detect Exec format error and fall back to ld.so, and at minimum surface the error instead of the sh script-fallback noise.

Downstream tracking: hivecommons/hive#17729.