[Bug Report] Language server crashes with SIGILL on CPUs without AES-NI support (Intel Celeron B815)
Summary
Antigravity language server crashes immediately on startup with a fatal SIGILL signal on processors that do not support AES-NI instructions. The main editor window launches successfully, but all AI features are unavailable.
Environment
Antigravity Version: 1.19.6-1772152296
OS: Linux Mint (Ubuntu Noble / 24.04 base)
CPU: Intel Celeron B815 @ 1.60GHz
AES-NI support: No (confirmed via /proc/cpuinfo)
Architecture: x86_64
Installation method: apt via Google repository (us-central1-apt.pkg.dev)
Steps to reproduce
Install Antigravity on a machine with a CPU that has no AES-NI support
Launch Antigravity
Observe the notification: *“Antigravity server crashed unexpectedly. Please restart to fully restore AI features.”
Clicking “Reload” does not help — crash loop repeats indefinitely
Error from logs
From exthost.log:
FATAL ERROR: This binary was compiled with aes enabled, but this feature is not available on this processor (go/sigill-fail-fast).
Language server killed with signal SIGILL
Failed to start language server: Error: Language server exited before sending start data
LS startLanguageServer error: Language server exited before sending start data
Activating extension google.antigravity failed due to an error:
Error: Language server has not been started!
From main.log:
SQLITE_READONLY_DBMOVED: attempt to write a readonly database
Extension host with pid 10575 exited with code: 0, signal: unknown.
Root cause analysis
The Antigravity language server binary is compiled with mandatory AES hardware acceleration. On processors without AES-NI (such as Intel Celeron B815 and other older/budget CPUs), the binary terminates immediately with SIGILL (Illegal Instruction). There is no software fallback.
Verification:
grep -o 'aes' /proc/cpuinfo
# returns empty — no AES-NI support
Expected behavior
Antigravity should either:
Ship a fallback binary without mandatory AES-NI requirement, OR
Detect missing CPU features at startup and display a clear, informative error message instead of a crash loop
Actual behavior
The language server crashes silently with SIGILL. The user only sees a generic “server crashed” notification with no explanation. The app enters an infinite crash-reload loop.
Additional notes
This affects a significant range of older Intel processors (pre-2012 Celeron, Atom, Pentium) that do not include AES-NI. These are commonly used machines in developing regions. A fallback build or a clear minimum requirements notice would greatly improve the experience for these users.
Please consider adding CPU feature detection at startup or providing a non-AES build. Thank you!
Welcome to the Forum!
A new version is now available. We recommend updating to the latest release and letting us know if you still experience this problem.
This means the issue affects not only CPUs without AES-NI, but ALL CPUs
without AVX-512 (pre-Haswell/Skylake, roughly pre-2013/2015).
The affected CPU range is significantly larger than reported.
The fix request remains the same: a fallback binary compiled with
GOAMD64=v1 or v2 would resolve both cases.
Subject: Confirmed on Celeron 2955U — CLI binary itself crashes, not just language server
I ran into this on a Chromebox running Ubuntu Server with an Intel Celeron 2955U (Haswell, 1.40GHz). A few findings that might help narrow down the fix:
The crash is in the agy CLI binary itself, not only the language server. It crashes before doing anything:
FATAL ERROR: This binary was compiled with aes enabled, but this feature is not available on this processor (go/sigill-fail-fast).
Illegal instruction (core dumped)
GODEBUG=cpu.all=off does not help — the check is baked in at compile time, not the standard Go runtime CPU detection path.
The binary has 2819 actual AES instruction calls (objdump -d $(which agy) | grep -cE "aesenc|aesdec|pclmul"), so this isn’t just a CPUID guard that can be nopped out — the binary genuinely requires AES-NI throughout.
strings confirms the binary also checks for pclmul, which is also absent on this CPU, so even if AES were somehow bypassed, pclmul would be the next crash.
This points to the binary being compiled at GOAMD64=v2 or higher. The Celeron 2955U has SSE4.1, SSE4.2, popcnt — all the other v2 requirements — but Intel stripped AES-NI and pclmul from the Celeron SKU.
Request: could Google ship a linux-x64-compat build compiled at GOAMD64=v1? The auto-updater service already has versioning infrastructure. A v1 build would cover Celeron, Atom, and similar stripped-SKU Intel CPUs without impacting anyone else.
The Raspberry Pi (aarch64) is also a dead end for the same reason — no ARM64 build exists at all.
I’m having the same issue sadly, both with the new CLI and Antigravity 2.0, because my Intel Core i7 860 doesn’t support AES-NI (ironically, if it were just one generation newer, it would have it, which sucks).
This is a major issue now that the Antigravity CLI is replacing the Gemini CLI, especially when other similar tools run with no issues at all. I mainly use AI tools as little copilots or rubber duckies to help me think through problems or fix stuff, not for “vibe-coding”, but it’s still a major downgrade.
I’m honestly thinking about canceling my Google One subscription because of this. I just can’t find a reason to keep paying for a service I can’t even use
it’s very clear that Antigravity is completely dependent on AES and will never deviate from it, to the point that they released Integrity CLi with the same problem. It seems almost essential to the application’s functionality. But what’s strange is that you replaced, or are planning to disable, Gemini cli, which works without any problems for everyone, and replace it with Antigravity CLi. A very strange decision indeed.
On June 18, 2026, Gemini CLI and Gemini Code Assist IDE extensions will stop serving requests for Google AI Pro and Ultra, as well as those using it free of charge using Gemini Code Assist for individuals.
Forcing everyone to migrate to a tool that crashes with a SIGILL on older CPUs without AES-NI support is a terrible decision. If they are actually killing the old CLI in less than a month, they must be planning to compile a version of Antigravity without the hard AES requirement. Otherwise, they are just intentionally dropping support for a huge chunk of the user base.
