Description
On corporate Linux workstations (SLES 15 SP4, kernel 5.14.21, glibc 2.31, x86_64) where ASLR is disabled system-wide via kernel.randomize_va_space = 0 (a common hardened-security baseline in some enterprise environments), the copilot binary crashes immediately with SIGSEGV on every invocation, including copilot --version and copilot --help. No output is produced at all before the crash.
The Node wrapper that launches the native binary reports:
GitHub Copilot native binary at .../node_modules/@github/copilot-linux-x64/copilot was terminated by signal SIGSEGV.
GitHub Copilot CLI: no platform package found. Reinstall with `npm install -g @github/copilot` to fetch the package for your platform.
This message is misleading — it suggests a missing/corrupt platform package, but the real cause is unrelated to installation integrity.
Steps to Reproduce
- On a Linux x86_64 host, disable ASLR:
sudo sysctl -w kernel.randomize_va_space=0
- Install/run
copilot --version (or --help)
- Observe immediate segfault (exit code 139), no output
Diagnosis performed
- Confirmed with a completely fresh, checksum-validated download (rules out corrupted install)
- Reproduced on multiple different physical hosts sharing the same OS/security baseline (rules out single-machine hardware fault)
- Reproduced on both the current release (v1.0.71/v1.0.72) and a release from ~2.5 months earlier (v1.0.40) (rules out a recent regression)
ldd on the binary shows all shared libraries resolve correctly (rules out missing-library issue)strace shows the process issuing a self-directed tgkill(pid, pid, SIGSEGV) very early during startup, consistent with a V8 sandbox/memory-reservation initialization failure that depends on ASLR being activeNODE_OPTIONS="--jitless" and other V8 flags do not prevent the crash (crash happens before/independent of JIT)- Re-enabling ASLR requires root (
sysctl -w kernel.randomize_va_space=2); this is not something an unprivileged CLI user can work around
Expected Behavior
Ideally the CLI would either:
- Run correctly with ASLR disabled (e.g., build V8 without the sandbox feature, or handle the reservation failure gracefully), or
- At minimum, detect this condition and print an accurate, actionable error message (e.g., "ASLR is disabled on this system; GitHub Copilot CLI's V8 runtime requires ASLR to be enabled") instead of the generic "no platform package found" message, which sends users down the wrong troubleshooting path (reinstalling, which does not help).
Environment
- OS: SUSE Linux Enterprise Server 15 SP4
- Kernel: 5.14.21-150400.24.158-default
- glibc: 2.31
- Arch: x86_64 (Xeon W-3245, AVX-512 capable)
- CLI versions tested: v1.0.40, v1.0.71, v1.0.72
kernel.randomize_va_space: 0 (disabled by corporate security policy)
Additional context
This affects an entire fleet of shared corporate Linux workstations that use a common hardened security baseline with ASLR disabled, blocking all Copilot CLI usage on those machines. We're separately requesting our IT team re-enable ASLR, but filing this so the CLI can (a) fail with a clearer error message and (b) ideally be made resilient to this configuration, since disabling ASLR is a real (if debatable) practice in some hardened/regulated environments.
Description
On corporate Linux workstations (SLES 15 SP4, kernel 5.14.21, glibc 2.31, x86_64) where ASLR is disabled system-wide via
kernel.randomize_va_space = 0(a common hardened-security baseline in some enterprise environments), thecopilotbinary crashes immediately withSIGSEGVon every invocation, includingcopilot --versionandcopilot --help. No output is produced at all before the crash.The Node wrapper that launches the native binary reports:
This message is misleading — it suggests a missing/corrupt platform package, but the real cause is unrelated to installation integrity.
Steps to Reproduce
sudo sysctl -w kernel.randomize_va_space=0copilot --version(or--help)Diagnosis performed
lddon the binary shows all shared libraries resolve correctly (rules out missing-library issue)straceshows the process issuing a self-directedtgkill(pid, pid, SIGSEGV)very early during startup, consistent with a V8 sandbox/memory-reservation initialization failure that depends on ASLR being activeNODE_OPTIONS="--jitless"and other V8 flags do not prevent the crash (crash happens before/independent of JIT)sysctl -w kernel.randomize_va_space=2); this is not something an unprivileged CLI user can work aroundExpected Behavior
Ideally the CLI would either:
Environment
kernel.randomize_va_space: 0 (disabled by corporate security policy)Additional context
This affects an entire fleet of shared corporate Linux workstations that use a common hardened security baseline with ASLR disabled, blocking all Copilot CLI usage on those machines. We're separately requesting our IT team re-enable ASLR, but filing this so the CLI can (a) fail with a clearer error message and (b) ideally be made resilient to this configuration, since disabling ASLR is a real (if debatable) practice in some hardened/regulated environments.