On Linux, I have antigravity 2.0 installed (and, woof, do better guys, I shouldn’t have to chmod/chown things to root as part of getting an app set up, it’s 2026). What’s interesting though is I’m still stuck on 2.0.0. When I click “check for update”, nothing happens. It appears that the app is trying to use electron’s update flow, but that apparently only works if the app is packaged as an appimage? In the terminal, I see
08:42:07.482 › APPIMAGE env is not defined, current application is not an AppImage
each time I clikc that check for update button. Has anyone managed to get 2.0.6 or 2.0.10 installed on Linux? The binaries from the Antigravity 2.0 site are still 2.0.0.
Pretty much what tuapuikia99 specified. I think the issue comes from that the old instructions wanted you to register certain package manager stuff (there were two repos supported IIRC). Currently is just a tar.gz. Un-compress it somewhere (e.g.: ~/.local/opt/Antigravity-x64/) and add it to your PATH at ~/.profile.
If you are on Arch there is a community managed package (this is what I currently use). There is also a community driven AppImage (haven’t tested it).
I was just double-clicking on the file in the file manager. I’ll try it with the xvpf flags. That being said, the issue with the permissions is secondary to the update function not working correctly.
I’m not pissed, per se. I pointed antigravity at itself and told it to fix it and it did. (Basically just repackaging antigravity as an appimage then running it causes the update to come down the pipe. And then every time you do that you need to delete chrome-sandbox from the appimage because appimages don’t run as root or some such.) But I do think it would be nice if they fixed it. Somehow every other appimage in existence manages this with less trouble.
Currently there are issues with linux updates ,Until Google fix this issue , you need to depend on tarball installation , I am sharing shell script for that , download latest anitgravity ide / 2.0 files from google , and run this script in same folder for **automatic installation
It doesn’t need to be executable, it needs to be +s and owned by root, and I’m pretty sure that a user being able to extract setuid binaries from randomly downloaded tarballs would have some pretty harsh security implications.
Package management in Linux has been solid for almost three decades now. That’s kind of its whole thing. Unsure why Google is still having a problem with this. Yes, I’ve been using Linux for a long time and I know how to do the surgery required to patch things up whenever there’s an update, but this is embarrassing. I was hoping it would have been fixed by now but it’s still broken today.
$ ./antigravity
[2912428:0614/055049.679493:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /home/pierce/Downloads/Antigravity-x64/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped) ./antigravity
I would rather download the tar.gz file and fix the chrome-sandbox permission. Removing --no-sandbox poses a security risk in case the page the browser opens has an RCE exploit.