[Bug] v2.0.1 Windows: Conversations still not associated with workspace — no workspace tag, always prompts “open in this workspace?”

Google Antigravity
1

Title: [Bug] v2.0.1 Windows: Conversations still not associated with workspace — no workspace tag, always prompts “open in this workspace?”

On Antigravity IDE v2.0.1 on Windows, I’m still seeing broken workspace association in Past Conversations.

Issue

When I open Past Conversations from the Editor sidebar:

  1. No workspace tag/badge
    Conversations that were created in the currently open workspace do not show a workspace tag. They look as if they belong to no workspace at all.

  2. Workspace disambiguation dialog appears every time
    Clicking any conversation — including conversations created in the current workspace — opens the dialog asking which workspace to open it in.

So the IDE behaves as if it does not recognize that the conversation already belongs to the currently open workspace.

This makes conversation switching very tedious, because every single click requires an extra confirmation step.

This did not happen before.

Possible relation to the old URI encoding bug from v1.22.2

Back in April, there was a detailed bug report on the Google AI dev forum describing a workspace URI encoding issue in Antigravity’s SQLite state database.

The old v1.22.2 behavior was roughly:

Turn 1 stored:
file:///c:/Users/...

Turn 2 overwrote it as:
file:///c%3A/Users/...

That mismatch caused conversations to disappear from the sidebar entirely.

In v2.0.1, the symptom seems different, but the underlying URI normalization problem may still be present.

I inspected my state.vscdb and storage.json.

storage.json — workspace folder URIs:

"folder": "file:///d%3A/coding/pocket"
"folder": "file:///d%3A/coding/feather"

state.vscdb — trajectory summaries / conversation index:

file:///d%3A/coding/pocket   (×3)
file:///d%3A/coding/feather  (×1)

Unencoded d: URIs found: 0

So the good news is that storage now appears consistent. Everything uses %3A.

Conversations also no longer disappear entirely.

The bad news is that the IDE’s runtime workspace comparison still seems to fail. My guess is that the active workspace URI used internally at runtime may still look like this:

file:///d:/coding/pocket

while the stored conversation index uses:

file:///d%3A/coding/pocket

If those are compared directly without normalization, Antigravity would fail to recognize the match.

That would explain why the IDE:

  • does not tag conversations with their workspace
  • thinks every conversation is “from somewhere else”
  • shows the workspace disambiguation dialog on every click

Steps to reproduce

  1. Open a workspace folder on a Windows drive-letter path, for example:
D:\coding\my-project
  1. Start a new agent conversation.
  2. Send at least two messages.
  3. Open Past Conversations in the Editor sidebar.
  4. Observe that the conversation has no workspace tag/badge.
  5. Click the conversation.
  6. Observe that Antigravity asks which workspace to open it in, even though the conversation was created in the current workspace.

Environment

Antigravity IDE: v2.0.1
OS: Windows 11
Workspace location: D:\coding\...

This may specifically affect workspaces on a non-C: drive, because the Windows drive-letter URI encoding seems to be the trigger:

D: → d%3A

It would be interesting to know whether users with workspaces on C:\ see the same behavior.

Workaround

I do not know of a real IDE-side workaround.

If you are switching conversations programmatically, for example through a companion app or automation tool, you can dismiss the workspace selection dialog automatically. But that is only a hack, not a fix.

Note to the dev team

The original issue seemed to be inconsistent URI encoding in storage. It looks like v1.22.2 → v2.0.1 may have fixed the storage consistency part, because both storage.json and state.vscdb now use %3A.

However, the runtime workspace comparison still appears to fail.

A likely fix would be to normalize workspace URIs before comparing the active workspace URI against the stored conversation workspace URI.

For example, compare after applying consistent URI decoding/encoding and case normalization, or use the existing normalized URI comparison utilities from the VS Code/Electron stack.

Something conceptually like:

decodeURIComponent(uri).toLowerCase()

The exact implementation may differ, of course, but the important part is that encoded and unencoded Windows drive-letter URIs should compare as the same workspace.