Antigravity CLI fails with Illegal Instruction (SIGILL) on legacy CPUs lacking AVX

Google Antigravity
,
1

Hi Antigravity Team,

I am reporting a compatibility issue with the Antigravity CLI on legacy x86_64 hardware. The binary fails immediately with an “Illegal instruction” error (Exit Code 132).

It appears the current binary is compiled with a modern baseline (likely GOAMD64=v3) that requires AVX instructions, which are missing on older but stable processors.

Environment details:

  • CPU: AMD A6-3420M APU (Lacks AVX support)
  • OS: OpenSUSE Tumbleweed (Kernel 7.0.7-1-default)
  • Error: Illegal instruction (Exit Code 132)

As a Google AI Pro subscriber, I rely on the CLI for my daily development workflow. I am requesting that the team provides a baseline x86_64-v1 binary (compiled with GOAMD64=v1) so users with legacy hardware can continue using the service after the mandatory migration on June 18th.

Reference to GitHub issue: Compatibility Issue: Antigravity CLI requires AVX instructions missing on legacy CPUs (AMD A-Series) · Issue #27342 · google-gemini/gemini-cli · GitHub

2

Is this support happening? what’s the latest?

3

Hi @srdjanrosic, thank you for following up on this. To answer your question: unfortunately, we haven’t received any definitive answer or timeline from the developers yet.

I would like to add more context for the Google team: as discussed in the GitHub repository (issue #27376), the current gemini-cli is scheduled for discontinuation on June 18th.

This creates a critical situation for users with legacy hardware (like my AMD A6-3420M). The current Node.js-based tool works perfectly, but the new Antigravity binary (likely compiled for
x86-64-v3) fails immediately with SIGILL.

Since the deadline is less than 3 weeks away, we urgently need a compatible build (targeting GOAMD64=v1) to ensure service continuity for Google AI Pro subscribers and users on older, yet capable, hardware. Is there an official timeline for a baseline/compatible release?

4

I can confirm this issue affects both the current v2.x release and the legacy v1.23.2 package from the APT repository.
▎
▎ System: Intel Celeron 1007U (Ivy Bridge, 2012) — supports SSE4.2 but no AVX. This maps to GOAMD64=v2 baseline.
▎
▎ v2.x: ~241,000 AVX instructions in the main binary → immediate SIGILL at startup.
▎
▎ v1.23.2: The language_server_linux_x64 binary contains internal/cpu.getGOAMD64level, ScanSpanPackedAVX512, and expandAVX512_* symbols, confirming it is
▎ also compiled above GOAMD64=v2.
▎
▎ The GODEBUG=cpu.aes=off workaround does not help — the crash occurs before the Go runtime can read environment variables.
▎
▎ There is currently no available version of Antigravity compatible with pre-Haswell CPUs. A build compiled at GOAMD64=v1 baseline would resolve this for
▎ a significant number of users still on older but functional hardware.
▎
▎ Please consider shipping a antigravity-linux-x64-compat variant, even as an unofficial/unsupported download.

5

Google is building the agy CLI using BoringCrypto with FIPS. Removing it will not pass the government requirement. This is a hard requirement.

6
  1. BoringCrypto Bridge Symbols: It contains hundreds of symbols like:
    • crypto/internal/boring.cgo…_Cfunc__goboringcrypto_AES_encrypt
    • crypto/internal/boring.cgo…_Cfunc__goboringcrypto_AES_decrypt
  2. FIPS Self-Tests: I found the explicit BoringSSL self-test symbol:
    • crypto/internal/boring.cgo…_Cfunc__goboringcrypto_BORINGSSL_bcm_power_on_self_test
  3. FIPS 140 Integration: It also contains references to the new crypto/fips140 module, which is the modern way Go handles these strict security
    boundaries.

AGY CLI binary is FIPS compliant.

7

Hi @tuapuikia99 and @Paolo_apeac, thank you for the deep dive.

The FIPS requirement mentioned by @tuapuikia99 is a crucial insight. However, this creates a major accessibility issue. While FIPS compliance is mandatory for government contracts, it
shouldn’t be a blocker for the general user base, especially for those of us on the Google AI Pro plan who are using perfectly functional (though legacy) hardware.

The current gemini-cli (Node.js) proves that high-level AI interaction doesn’t strictly require these modern hardware instructions. If the new CLI is meant to replace it entirely by June
18th, Google should provide a non-FIPS/baseline build for the developer community.

Locking out users on hardware like the AMD A-series or Ivy Bridge CPUs — which are still widely used for development in many regions — seems like an unnecessary barrier. We are not asking to remove FIPS from the main branch, but to provide an alternative “compat” build for those who prioritize service continuity over government-grade certification.

8

Hi @tuapuikia99 and @Paolo_apeac. Today is June 17th, the day before the scheduled transition.

I’ve conducted a final technical test using the Intel Software Development Emulator (SDE 10.8) to attempt AVX emulation on my AMD A6 system. The emulator itself failed with SIGILL,
confirming that the current binary environment is too restrictive for standard software-level workarounds.

Regarding the FIPS/BoringCrypto requirement: while the security implications are clear, the lack of a baseline GOAMD64=v1 variant means that starting tomorrow, the service becomes
effectively inaccessible on this hardware. As a Google AI Pro user, if a compatible build isn’t provided, I will have no choice but to explore other AI platforms and CLI tools that support
broader hardware standards to maintain my development workflow.