One morning the project list in my sidebar had grown long enough that I wanted to tidy it up. My hand stopped over the delete control, because I couldn't say in my own words what would happen to the folder once I pressed it.
I'm clearly not the only one wondering. A Zenn post on how Antigravity 2.0 projects relate to local folders walks through exactly this question, and its answer is that your files stay. The author is also upfront that some of the cleanup advice was not verified.
I should say the same about this piece: I haven't pressed delete and compared folder contents before and after. What I did instead was turn the checks you can run beforehand, without touching anything, into something I'd use on my own indie-developer repositories.
Reading "it stays" as two separate storage locations
As I read the post, a project is a reference to a working folder, and the data lives in two places.
| Location | What it holds | Effect of delete, as described |
|---|---|---|
| Your working folder | Source code, .git, instruction files such as .agents/ and GEMINI.md | Described as untouched |
| Antigravity's internal area (~/.gemini/antigravity/) | Conversation history, reasoning logs, generated files, per-project permissions | Registration and the link to your conversations are removed |
The line I want to draw is between "it is written that it stays" and "I confirmed that it stays." The post shows Windows paths; on macOS I'd expect ~/.gemini/antigravity, but a quick ls on your own machine is the only way to know.
Before pressing anything, I want to be able to name what remains. For me that came down to three things:
- Committed source code in the working folder
- Uncommitted changes and files Git doesn't track
- The files that instruct the agent: .agents/, GEMINI.md, AGENTS.md
The second one is the blind spot. A file Git ignores, such as .env, can't be restored from the repository. Even if deletion never reaches it, some other accident might, so I like to see it exist once.
A read-only script that counts what remains
This script only reads. There is no delete or move anywhere in it.
#!/usr/bin/env bash
# Pre-delete check (read-only). Usage: ./preflight.sh /path/to/project
set -u
proj="${1:?Pass the project folder}"
echo "== 1. Uncommitted changes and untracked files (first 20 lines)"
git -C "$proj" status --short | head -n 20
echo "== 2. Files Git ignores (.env and friends cannot be restored)"
git -C "$proj" status --short --ignored | grep '^!!' | head -n 20
echo "== 3. Commits not yet pushed"
git -C "$proj" log --oneline '@{u}..HEAD' 2>/dev/null | head -n 10
echo "== 4. Agent instruction files"
ls -d "$proj"/.agents "$proj"/GEMINI.md "$proj"/AGENTS.md 2>/dev/null
echo "== 5. Internal area size (largest 8 entries)"
du -sh "$HOME"/.gemini/antigravity/* 2>/dev/null | sort -h | tail -n 8Here is why each block is there. Checks 1 and 3 make visible any work that exists only on your machine, even if you trust that source code survives. Check 2 picks up what lives outside Git; if a .env or a key shows up, I look for a copy elsewhere first. Check 4 simply lets me see that the agreements I wrote for the agent sit in the working folder. Check 5 has nothing to do with deleting; it is a map for later, when you want disk space back.
I ran it against a small throwaway repository and confirmed that an untracked file and an ignored .env both appeared in the output. On a real project the output will be longer.
Renaming the folder in your OS breaks the link
The same post says that renaming a project inside the app only changes its display name, while renaming the folder in Finder or Explorer breaks the association. The suggested way back is to open the new location and type @ in the prompt box to pull in the earlier conversations.
I haven't tried that on a production repository yet. If you'd rather not rely on it, tidying up project granularity and conversation names beforehand is the surer route, and I wrote down the order I used in a sidebar organization guide for when you have a dozen Antigravity projects.
Before you ask the agent to free disk space
The internal area grows because browser-automation recordings and per-conversation artifacts pile up; the post says it can reach several to tens of GB. I understand the urge to reclaim that space.
But please pause before asking the agent to "clean the cache." There have been reports of path misinterpretation deleting far more than intended. I wrote up a small gate that narrows how far a delete can reach in this piece on a cache cleanup that ended up removing a whole drive.
My order is: delete finished conversations from the app's history first; if that isn't enough, look at what is large with du; delete by hand last. And if your conversation store is SQLite, deleting rows often doesn't shrink the file, which I covered in why a conversation database doesn't shrink even after duplicates are removed.
One sentence before pressing delete
Press delete only once you can name three things that stay. That is the whole rule I settled on.
If you have a project you haven't touched in months, run the script above on its folder once. If nothing unfamiliar turns up, you can tidy up without that knot in your stomach.