When Antigravity Says the Server Crashed Unexpectedly: Check the CPU, WSL, or Version First?

Following the dialog's advice and restarting is the natural first move. But when the same message comes back after every restart, that one sentence stops being a clue.

"Antigravity server crashed unexpectedly. Please restart to fully restore AI features." The editor window opens fine, and only the AI side falls over right after startup. Searching the forum turned up many threads with this exact wording, and the environments were all different: an old AMD CPU on Linux, Pop!_OS, WSL, a remote SSH host. It was after reading about four of them side by side that I realized the same message was covering more than one cause.

I should say plainly that I haven't reproduced this on my own machines. So this isn't a record of something I fixed. It's my attempt, as an indie developer reading public reports, to order the checks so you lose less time. Where something is unconfirmed, I'll say it's unconfirmed.

One message, at least three different stories

From what I read, the reports fall into three groups.

The point is that none of these rows can be stated as "the cause". I couldn't find a thread with an official explanation from the developers.

That is exactly why the order of checks has value. Rather than guessing the cause, it's more realistic to find which row your environment resembles, in a few minutes.

One script gets you the facts you need first

In nearly every thread, the same information was missing at the start: CPU, OS, whether it's WSL, and the version. Posters often added "actually, this is WSL1" several replies later.

If you collect it yourself first, both triage and writing a question get easier. Here is a minimal script that works on Linux and inside WSL.

#!/usr/bin/env bash
# ag_triage.sh: print what you need to triage "server crashed unexpectedly".
# It changes nothing. Read-only.
 
echo "== CPU =="
grep -m1 'model name' /proc/cpuinfo
# -w matches the word "aes" only, so similarly spelled flags don't interfere
if grep -qw aes /proc/cpuinfo; then
  echo "aes flag: present"
else
  echo "aes flag: missing  <- look at the CPU group first"
fi
 
echo "== OS =="
. /etc/os-release 2>/dev/null && echo "$PRETTY_NAME"
uname -m   # if not x86_64 (e.g. aarch64), look for a different group of reports
 
echo "== Execution path =="
if grep -qi microsoft /proc/version 2>/dev/null; then
  if uname -r | grep -qi 'wsl2'; then echo "Inside WSL2"; else echo "Inside WSL (no WSL2 marker; possibly WSL1)"; fi
fi
[ -n "$SSH_CONNECTION" ] && echo "Shell over SSH"
 
echo "== Server-side working directories =="
ls -d "$HOME/.antigravity-server" "$HOME/.gemini/antigravity" 2>/dev/null || echo "neither found"

Typical output looks like this.

== CPU ==
model name	: Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
aes flag: present
== OS ==
Ubuntu 22.04.4 LTS
x86_64
== Execution path ==
Inside WSL2
== Server-side working directories ==
/home/user/.antigravity-server

A short note on grep -w: the flag list contains similarly spelled entries, and a loose match can mislead you. If it prints "missing", also consider whether a virtual machine is simply hiding the CPU feature. On a VM, a host CPU that supports AES can still look different to the guest.

The first lines decide where to look next

If aes is missing. In the reports I read, this group consistently has one trait: the window opens, only the agent dies. Whether AES is truly required is, as far as I could verify, unconfirmed. In fact, the Pop!_OS reporter confirmed AES support and still hit the same message. So treat the aes flag as a way to prioritize suspects, not as proof of cause.

If it's missing and nothing else fits, giving up on AI features on that particular machine for now is a realistic call. I'd move the agent work to a newer machine and keep the old one for tasks that don't need it.

If it's WSL or SSH. Check three things, lightest first.

1. Is it WSL 1 or 2? Run wsl -l -v on the Windows side and read the VERSION column. One reply suggested upgrading WSL1 to WSL2, but nobody in the thread confirmed that it fixed anything.
2. Can you try another network? In one thread, a phone tether worked while a particular ISP box did not. That was described as a workaround, not a fix. Behind a corporate proxy, this note on isolating proxy and firewall problems may help.
3. Recreate the server-side directory (.antigravity-server inside WSL). The reporter tried it without success, but leftovers could be the cause in a different environment. Move it aside instead of deleting it, so you can put it back.

If neither applies and an old version is suspected. In the Pop!_OS report the problem seemed to disappear in 1.20.4, so updating does sometimes help. But a newer version can bring its own problems, so note your current version before updating. I wrote about pinning versions for repeatable scheduled runs in this piece on version pinning for the CLI.

What I would not try first

One thread described repeated full reinstalls. They didn't help.

I understand the impulse. On a night when an app misbehaves for no visible reason, my own hand drifts toward reinstalling too. But a reinstall drags settings and history along with it. Before you have the triage facts, even a successful reinstall leaves you not knowing what worked. Run the script once before reinstalling. That's an order I try to keep.

What to include when you post on the forum

There are already many threads with this wording, and a post with thin environment details is hard to act on. Paste the script output as it is, and add these four items.

• The Antigravity version (the About screen or similar)
• What you did just before it started (an update, a proxy change)
• What you tried and what happened ("it didn't help" is useful too)
• Whether Windows alone works, or only WSL or the SSH host crashes

Each fits on one line.

Your next step

Run ag_triage.sh once and keep the output in a note. With the aes flag, the WSL version and the Antigravity version filled in, you can usually tell which of the three groups you are closest to within minutes.

I don't know whether an official explanation will arrive. Still, if your environment's facts are already lined up, you'll be able to compare against it the day it does.