Product: Antigravity IDE (v1.104.0) OS: Windows 11 (Client) → Ubuntu VPS (Remote)
Issue Description: I am unable to use the Remote-SSH feature to connect to my Linux server. The connection initiates, but the server agent crashes almost immediately during the handshake.
Behavior:
I start the Remote-SSH connection.
A Windows Command Prompt window opens (likely the SSH tunnel helper) but hangs indefinitely and remains blank (see Screenshot 1).
The IDE eventually shows the error: “Antigravity server crashed unexpectedly. Please restart to fully restore AI features” (see Screenshot 2).
The file explorer may show the directory structure for a split second before the crash.
Important Context:
VS Code and Cursor work perfectly on this exact same server via SSH. I can edit files and run terminals without issues in those IDEs.
The server is a standard Ubuntu VPS (glibc 2.39).
Logs & Investigation: Since the UI didn’t provide much detail, I SSH’d into the server manually to run the Antigravity server binary directly.
The process terminates immediately with Exit Code 132.
Looking at the kernel logs (dmesg), I see the following error generated exactly at the time of the crash: traps: antigravity-ser[PID] trap invalid opcode ip:...]
Potential Cause / Hypothesis: My VPS runs on a virtualized CPU (QEMU Virtual CPU version 2.5+). I noticed this CPU profile exposes standard flags (SSE, AES) but does not explicitly list AVX/AVX2 flags. Could the Antigravity agent be compiled with stricter CPU instruction set requirements than VS Code/Cursor?
Has anyone else encountered this “Invalid Opcode” crash on standard VPS hosting?
Quick update (can’t upload screenshots right now):
I realized that the SSH connection doesn’t completely drop. I can actually browse and edit files normally. Also, correction on my initial post: the empty CMD window actually closes correctly once I enter my password, so the handshake seems fine.
However, the AI features are dead on arrival with the “server crashed unexpectedly” error immediately after login.
It turns out this is definitely a CPU instruction set issue. My VPS runs on QEMU and lacks AVX support (only has SSE/AES). The Antigravity agent dies with Exit Code 132 (Illegal Instruction) right at startup.
What’s frustrating is that Cursor works perfectly fine on this exact same server (including its AI features). It seems Antigravity’s remote binary is compiled with stricter hardware requirements than competitors.
Is there any flag to run the agent in compatibility mode?
Thank you for flagging the issue. We have escalated the issues with Remote-SSH internally.
To ensure our engineering team can investigate and resolve these issues effectively, we highly recommend filing bug reports directly through the Antigravity in-app feedback tool. You can do this by navigating to the top-right corner of the interface, clicking the Feedback icon, and selecting Report Issue.
To be clear, I have already submitted a comprehensive in-app feedback report that includes the description of the issue.
I prefer not to post my account email publicly in this thread for privacy reasons.
Since in-app feedback acts as a one-way communication channel (I don’t receive ticket numbers or status updates), should I simply monitor this thread for news regarding a fix for this issue?
Thank you for submitting the in-app feedback report. For your privacy, there is no need to share your email address in this public thread. We will post an update here as soon as we hear back from the engineering team regarding the Remote-SSH issue.
Hi, i also have the same problem trying to conenct to an RaspberryPi4 via remote-ssh. Antigravity crashes with error ” Antigravity server crashed unexpectedly. Please restart to fully restore AI features.”
In runtime status i can see some errors “ Menu item references a command antigravity.importAntigravitySettings which is not defined in the ‘commands’ section” , dont know if it’s related to the crash.
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16)
[Error - 9:09:46 AM] Restarting server failed
Error: connect ECONNREFUSED 127.0.0.1:46691
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16)”
A month ago it wasn’t working at all, and now I can occasionally get a connection and do some work, but the server disconnects keep happening intermittently. I suspect Cursor is running in a smaller, resource-efficient environment. My remote server probably can’t handle this workload, which is why the connection is lost or the server process simply closes due to insufficient resources.
It would be fantastic if this could be fixed, as I really enjoy working with Antigravity.
Following up on this, I’m using a Raspberry Pi 4 Model B and I’ve been running into the same Exit Code 132 (SIGILL) since version 1.15.8 (commit 7a86575).
After some debugging, I’ve confirmed that the issue is a specific architecture mismatch in the language_server_linux_arm binary. It appears the current build targets ARMv8.2-A (using FEAT_DotProd instructions), but the RPi 4 uses a Cortex-A72 which is strictly ARMv8.0-A.
Technical Proof: I ran objdump -d on the server’s language server binary and found multiple udot instructions that are physically unsupported by the hardware:
# Snippet from objdump -d on language_server_linux_arm:
670e9e4: 6e8094a4 udot v4.4s, v5.16b, v0.16b
My kernel logs (dmesg) also report the instruction trap precisely when the agent tries to start: traps: language_server[...] trap inline_attempt_udot instruction_failed
Temporary Workaround for RPi 4 users: While we wait for a fix, I found a way to at least keep the connection alive so the editor remains usable. If you “neutralize” the problematic binary, the main server starts fine:
Go to the binary folder: ~/.antigravity-server/bin/[COMMIT]/extensions/antigravity/bin/
Back up the original: mv language_server_linux_arm language_server_linux_arm.bak
Create a dummy replacement to prevent the crash loop:
This allowed me to reconnect and edit files, although local AI features are obviously disabled. Hopefully, the dev team can adjust the compiler flags to include ARMv8.0-A or add a runtime feature check.
Try to turn off your antivirus.
If it works on other people’s machines but not on yours, the problem is with your machine.
Some software is on the way…