Antigravity CLI Conversation History: Where It Lives and How to Resume

Resuming a conversation: the two commands

# Start a fresh session in the current directory
agy

# Continue your most recent conversation, wherever you left it
agy -c

# Resume a specific conversation by id
agy --conversation <id>

agy -c is the one you will use ninety percent of the time. It picks up your most recent conversation exactly where it ended, with the full context intact, which is what you want after stepping away for lunch or reviewing a diff and deciding the agent needs another pass.

agy --conversation <id> is for everything else: the session from Tuesday, the one on the other project, the one you abandoned halfway and now want to finish. It needs the conversation id, and getting hold of that id is the part nobody documents.

Where the history actually lives

Antigravity reuses ~/.gemini as its home directory, and conversations sit under ~/.gemini/antigravity-cli/.

The important structural fact is that they are stored flat. There is no directory per project and no nesting by workspace: every conversation from every project you have ever worked on lands in the same folder, identified only by its id. If you are used to agents that organise history into a folder per repository, this will look wrong the first time you see it.

Each conversation is represented by two things: a transcript in JSONL, which is the clean, readable record of the exchange, and a per-conversation SQLite database named after the conversation id. The transcript is what you would read; the database is where the interesting metadata hides.

The project problem: the transcript does not know where it ran

Here is the detail that makes flat storage genuinely awkward rather than merely untidy: the clean transcript carries no working directory and no workspace field. Open a conversation JSONL and you can read every message, but nothing in it tells you which repository the agent was working in.

With one project that does not matter. With five, you have a single flat folder of conversations and no way to tell from the transcript which ones belong to which codebase, which is exactly when you most need to find an old session.

The information does exist, but it is in the per-conversation database rather than the transcript, and it arrives by one of two routes depending on how the session was started:

• A registered workspace. When agy starts inside a workspace it recognises, the database records the workspace as an absolute file:/// path in its trajectory metadata. This is the authoritative answer when it is present.
• No registered workspace. Sessions that were not started in a recognised workspace, which includes agy launched from inside a plain project directory, have no such path. For those, the only signal is the working directory that the agent's own shell commands ran in, recorded step by step in the database.

The practical consequence: a tool that reads only the transcript cannot label your conversations correctly, and will fall back to a generic label. Recovering the real project means reading the database and taking whichever of those two signals is available.

Two habits that save you the archaeology

You can avoid most of the above by changing how you work rather than by digging through SQLite.

Reach for -c before you reach for an id. The most recent conversation is always one keystroke away and needs no lookup. If you are disciplined about finishing one thread before starting another, you will rarely need to resume by id at all.

Note the id when a session matters. If you are stopping mid-task on something you will definitely come back to, the id is worth thirty seconds in a scratch file or a commit message. Finding it later costs considerably more than that.

Searchable history across every session

The flat-storage-plus-missing-project combination is manageable with one agent on one project and genuinely painful once you have dozens of conversations across several repositories. You end up knowing that a session exists in which you solved a problem, and having no reasonable way to find it.

CodeAgentSwarm, the desktop workspace for running several AI CLI agents in parallel, indexes Antigravity conversations and gives you full-text search across all of them, with each conversation attached to its real project. It resolves the project by reading the per-conversation database and taking the registered workspace where one exists, falling back to the dominant working directory of the session's own shell commands where it does not, which is the same two-signal approach described above.

From there you can reopen any conversation in a terminal directly, without hunting for an id. It works the same way across your other agents, so a mixed setup of Antigravity, Claude and Codex sessions is searchable from one place, which pairs with the pattern in the Antigravity agent swarm guide.