What caught my eye in the forum report was a single detail: the freeze happens even with an empty folder. That takes "the repository is too big" off the table.
I should say up front that there is no confirmed fix that I can find. The report comes from Parrot OS (Debian-based) on Wayland, a GeForce GTX 1060, driver 550.163.01, and Antigravity 1.107.0 installed from the APT repository. About 15–20 seconds after the window opens it becomes unresponsive, and the log repeats "CodeWindow: detected unresponsive" at the same interval.
I work on a Mac as an indie developer, so I haven't reproduced this. What follows is a triage order drawn from the report, not a guaranteed cure.
Cross off what already failed
The reporter tried all of these without improvement:
- Launching with
--disable-extensions - Launching with
--disable-gpu - Raising
fs.inotify.max_user_watchesto 524288 - Wiping
~/.config/Antigravityand reinstalling - Opening a folder that holds a single file
If you are in the same spot, you don't need to repeat them. Extensions, GPU rendering, the file-watch limit, corrupted settings and folder size are all ruled out on at least one machine.
What remains, one change per launch
When I'm stuck I tend to change several things at once, and then I can't tell what helped. These days I change one item per launch.
1. Change the session type
Since --disable-gpu didn't help, rendering alone is unlikely. Wayland versus X11 sits in a different layer, though. Check where you are first:
echo "$XDG_SESSION_TYPE"
nvidia-smi --query-gpu=name,driver_version --format=csvThen try launching as an X11 window. --ozone-platform is a Chromium option; I haven't confirmed how the IDE handles it, so it may be ignored.
antigravity --ozone-platform=x11Choosing an X11 session at the login screen is the more reliable variant of the same test.
2. Launch with the network off
The reporter guesses the main thread blocks while sorting and selecting the model list (setSelectedModel) at startup. That is a hypothesis, not a confirmed cause, but it is cheap to test. If the list depends on a network call, behavior should change offline.
nmcli radio wifi off
antigravity
nmcli radio wifi on # restore afterwardsIf the freeze changes or disappears, look at networking and account state. If nothing changes, the hypothesis weakens.
3. Start from a clean data directory
A reinstall didn't help, so user settings are an unlikely culprit. Still, pointing at a fresh directory guarantees nothing is carried over:
antigravity --user-data-dir /tmp/ag-clean --disable-extensions4. Count the repeats in the log
Look at how often "detected unresponsive" appears and what is printed just before it. Log locations vary by version, so search under ~/.config/Antigravity:
grep -rn "unresponsive" ~/.config/Antigravity/logs 2>/dev/null | head -20If the line before it is always the same, that is the entrance to the stall, and it makes a far better forum post.
What to include when you report
- Distribution and session type (Wayland or X11)
- GPU model and driver version
- Antigravity version and install method
- Which of the steps above you tried, and the result of each
- The interval between "unresponsive" lines and the log lines before them
Record what you ruled out before you record what you suspect. That habit has saved me on the long debugging days.
Start by noting the output of echo "$XDG_SESSION_TYPE" and how the IDE behaves offline. If you need to tell this apart from a language-server stall, what to check before restarting a language server may help.