[Bug] Antigravity CLI/IDE Language Server crashes with SIGILL (go/sigill-fail-fast) on architectures lacking AES-NI / AVX-512 extensions

Google Antigravity
1

Title

[Bug] Antigravity CLI/IDE Language Server crashes with SIGILL (go/sigill-fail-fast) on architectures lacking AES-NI / AVX-512 extensions

Environment

  • Product: Google Antigravity IDE / Antigravity CLI (agy)

  • Version: 2.0.0 / 1.0.2

  • Operating System: MXLinux 25 (Debian 12/Wormhole base, x86_64)

  • Host CPU Architecture: Legacy Intel Core 2 Duo / Celeron / Early Core Series (Missing aes and pclmulqdq instruction flags in /proc/cpuinfo)

Summary

The Go-based companion microservices (agy install binaries and the desktop IDE’s internal /opt/antigravity/resources/bin/language_server) terminate instantly with a SIGILL (Illegal Instruction) crash on startup. This behavior occurs on legacy x86_64 processors that do not support hardware-accelerated AES-NI or AVX-512 extensions.

The application fails during compile-time verification routines before standard runtime environment variable overrides (such as GODEBUG=cpu.aes=off) can be loaded or interpreted by the Go runtime handler.

Steps to Reproduce

  1. Install the standalone Antigravity 2.0 app on a Linux platform with a CPU that lacks hardware native AES-NI extensions.

  2. Launch the application from either an XFCE launcher entry or directly via the binary path.

  3. Observe the DevTools crash sequence or UI fatal dialog stating that the Language Server failed to initialize.

Expected Behavior

The application should run an initial runtime hardware capability query (e.g., via cpu.X checks). If missing features are detected, it should cleanly fall back to a pure software-based cryptographic matrix implementation or display a clear minimum-hardware error notification.

Actual Behavior / Log Output

The parent Electron/Chromium host starts up successfully, but the backend child process drops offline immediately, generating the following terminal dump:

Plaintext

DevTools listening on ws://127.0.0.1:44665/devtools/browser/1a51f79c-2fb5-4afc-9829-91bac707dd8b
14:58:00.981 › Failed to get LS stamp: Error: Command failed: /opt/antigravity/resources/bin/language_server --stamp
FATAL ERROR: This binary was compiled with aes enabled, but this feature is not available on this processor (go/sigill-fail-fast).
/opt/antigravity/resources/bin/language_server: line 2:  6405 Illegal instruction     GODEBUG=cpu.aes=off /opt/antigravity/resources/bin/language_server.bak "$@"

    at genericNodeError (node:internal/errors:985:15)
    at wrappedFn (node:internal/errors:539:14)
    at ChildProcess.exithandler (node:child_process:417:12)

Root Cause Analysis

An inspection of the binary indicates that the Go components are compiled with a microarchitecture baseline targeting higher modern tiers (potentially GOAMD64=v3 or with explicit hardware encryption directives hardcoded into the pipeline). This completely bypasses standard Go runtime diagnostic overrides.

Running objdump -d on the binary exposes deep integration of direct vector execution commands (such as vaesenc, vpclmulhqhqdq, or aesenc) throughout the core package, triggering an uncatchable kernel signal trap on older hardware execution threads.

Proposed Remediation

  • Please introduce a legacy-compatible fallback option into the automated package configuration system.

  • Shipping a secondary target flavor (e.g., antigravity-linux-x64-compat) compiled strictly at a GOAMD64=v1 baseline would restore support for developers on older hardware platforms without compromising performance paths for modern processing rigs.

1 Like