[Bug] v1.22.2 Regression: Conversations disappear from Editor sidebar after the 2nd message (URI encoding mismatch)

Hi everyone,

I’ve run into a frustrating issue in the latest Antigravity update (v1.22.2 on Windows), and after doing some deep-dive debugging into the SQLite global storage, I wanted to share the exact root cause here so the dev team can patch it (and to help anyone else going crazy over disappearing chats!).

The Issue: When you start a new conversation in the Editor panel sidebar, everything looks fine after the first message. But the moment you send the second message, the conversation suddenly vanishes from the active workspace’s Editor panel. You can still find it in the global Agent Manager, but it refuses to stay pinned to your workspace.

Steps to Reproduce:

  1. Open a local workspace folder on Windows (e.g., C:\Users\Name\Desktop).

  2. Ensure you are on Antigravity v1.22.2.

  3. Start a new agent chat in the Editor panel.

  4. Send message #1 → Chat stays in the panel.

  5. Send message #2 → Chat instantly disappears from the panel.

The Root Cause (Deep Dive): I inspected the state.vscdb database and the raw protobuf data inside antigravityUnifiedStateSync.trajectorySummaries. This seems to be a regression related to URL encoding of the workspace URI.

  1. Turn 1 (Creation): The conversation is indexed with a raw drive letter matching the workspace (e.g., file:///c:/Users/...). It matches the active workspace, so the UI displays it.

  2. Turn 2 (Update): When the IDE syncs the conversation state after the second message, a regression in the sync logic explicitly URL-encodes the drive letter colon, overwriting the protobuf state to file:///c%3A/Users/....

  3. The Drop: Because c%3A no longer strictly matches the active workspace URI (c:), the UI assumes the conversation belongs to a different workspace and removes it from the current sidebar.

(Note: The actual .pb file on disk inside ~/.gemini/antigravity/conversations/ remains correct, this is purely an index sync issue in state.vscdb.)

Temporary Workaround: Downgrading to v1.21.9 completely resolves the issue, as the URI encoding logic in that version was consistent. I could not find a way to fix this locally on v1.22.2 because every new message forces the database to overwrite with the buggy %3A format.

Has anyone else noticed this behavior on Windows? Hoping the Antigravity team can push a quick fix for this in the next patch!

2 Likes

how do they even push out buggy,faulty updates without even testing them??? i’m having an issue in latest version, it keeps searching forever

2 Likes

Same here. Its too irritating

1 Like

Same thing. Had to uninstall newest version and install the previous one. But it has no sense, since every sent message getting auto reply “Our servers expecting high traffic and bla bla bla“
Impossible to use