Corrupted Conversation File Causes Silent Chat Failure & History Loss

Google Antigravity
1

Bug Report: Corrupted Conversation File Causes Silent Chat Failure & History Loss

Product: Antigravity (VS Code-based IDE)
Platform: Windows 11
Severity: Critical — Silent total loss of functionality with no recovery path
Date: April 2026

Summary

A corrupted .pb conversation file causes Antigravity to enter a broken state where:

  1. The app launches and appears completely normal — no crash, no error message, no banner.
  2. All conversation history disappears from the sidebar.
  3. The chat interface silently fails — it accepts user messages but never produces any response. No spinner, no error, no timeout message. Just silence.
  4. This affects all models — switching between Claude, Gemini, etc. makes no difference. The entire chat/agent backend is non-functional.

The user is left staring at a perfectly normal-looking UI that simply does nothing, with zero indication of what went wrong.

Log Evidence

The following errors appear in ls-main.log during the broken sessions. These are the only indicators that anything is wrong — nothing is surfaced to the user.

Error 1: Failed trajectory load (cascade_manager.go)

E0422 14:14:43.682232 <PID> cascade_manager.go:539] Failed to load trajectory 
<conversation-uuid-A> on-demand: failed to load trajectory 
<conversation-uuid-A>: open <user-home>/.gemini/antigravity/
conversations/<conversation-uuid-A>.pb: The system cannot find 
the file specified.

The language server’s cascade manager fails to load a conversation trajectory because the .pb file is missing or corrupted. This error is logged but not propagated to the UI.

Error 2: Agent state not found (interceptor.go)

E0422 14:14:43.682232 <PID> interceptor.go:74] 
/LanguageServerService/StreamAgentStateUpdates (unknown): 
agent state for conversation <conversation-uuid-A> not found

The gRPC StreamAgentStateUpdates call fails because the agent state for the conversation cannot be located. This appears to break the entire agent state streaming pipeline, which is why all subsequent messages (even to new conversations) receive no response.

Error 3: Unexpected end of JSON input (log.go)

E0422 14:14:43.755141 <PID> log.go:398] unexpected end of JSON input

A JSON deserialization error occurs immediately after the trajectory load failure, suggesting the corrupt .pb data (or a related index entry) is being parsed as JSON and failing.

Error 4: Terminal shell support failure

E0422 14:14:43.735901 <PID> log.go:398] failed to check terminal shell support: 
internal: internal error

This may be a cascading failure from the agent state corruption — the terminal integration also fails.

Key observation: All four errors occur at the same timestamp (~14:14:43), suggesting a single corrupt file triggers a cascade that breaks the entire language server agent backend. The language server continues running (it doesn’t crash), but the agent functionality is silently dead.

Root Cause

Conversation history is stored as protobuf (.pb) files in:

<user-home>/.gemini/antigravity/conversations/<conversation-id>.pb

When a .pb file becomes corrupted (cause unknown — possibly a write interrupted by a crash or power event), the application has no error handling around deserialization of these files.

The failure chain:

  1. The corrupted conversation was open as an editor tab in a workspace before the corruption occurred.

  2. The open-tab reference is persisted in the workspace’s SQLite state database:

    %APPDATA%/Antigravity/User/workspaceStorage/<workspace-hash>/state.vscdb

    Specifically under keys like memento/workbench.parts.editor and memento/antigravity.jetskiArtifactsEditor.

  3. On launch, Antigravity attempts to restore the workspace state and load the corrupt .pb file. The language server’s cascade_manager.go fails to load the trajectory, interceptor.go fails to find the agent state, and the entire agent state streaming pipeline silently breaks.

  4. The UI renders normally but no messages are processed — the chat is completely inert.

  5. Because there are no user-facing diagnostics, the user has no way to identify the cause.

Additional discovery: AppData conversation index cannot be rebuilt

During recovery attempts, we tried booting with a fresh %APPDATA%/Antigravity directory. The app launched without the silent failure, but all conversation history was permanently gone — even though all the .pb files and brain directories were intact on disk. Antigravity does not rebuild its conversation sidebar index by scanning the .gemini/conversations folder. The index lives exclusively in the AppData state databases, and losing it means losing all conversation references.

Impact

  • Complete loss of chat functionality with no visible error or indication of what’s wrong.
  • Complete conversation history loss — even after resolving the silent failure, conversations only reappear if the original AppData state databases are restored.
  • No diagnostics whatsoever. The errors only appear in ls-main.log which users would never think to check. The UI gives no hint.
  • Recovery required ~6 hours of manual forensics across multiple agent sessions, including: writing custom Node.js scripts to query internal SQLite databases, binary-searching through 105+ .pb files to identify the corrupt ones, and surgically reconstructing the AppData directory while removing specific workspace state entries.

Steps to Reproduce

  1. Have a conversation open as an active editor tab in an Antigravity workspace.
  2. Corrupt the corresponding .pb file in .gemini/antigravity/conversations/. (This happened organically — likely from a write interrupted by a crash.)
  3. Close and reopen Antigravity.
  4. Result: App launches normally. Conversation history is gone. Send any message in the chat — it is accepted but no response is ever generated. No error is shown. All models exhibit the same behavior.

Suggested Fixes

P0 — Prevent the silent failure

  1. Wrap trajectory loading in try/catch in cascade_manager.go. If a conversation .pb file fails to load, log a warning, skip that conversation, and continue initializing the agent backend normally. A single bad file should never take down the entire StreamAgentStateUpdates pipeline.
  2. Isolate conversation failures. The failure of one conversation’s trajectory load should not prevent other conversations or new conversations from working. The error in interceptor.go suggests the agent state stream breaks globally.
  3. Validate editor tab references on startup. Before restoring workspace editor tabs, verify that the referenced conversation file exists and is parseable. If not, remove the tab reference from the workspace state rather than attempting to load it.

P1 — Enable recovery

  1. Add a conversation index rebuild mechanism. If the AppData state becomes corrupted or is lost, the application should be able to rescan .gemini/antigravity/conversations/ and .gemini/antigravity/brain/ to reconstruct the conversation sidebar index. Currently, a fresh AppData means permanent loss of all conversation history references, even though the underlying data files are intact on disk.
  2. Add a “Safe Mode” launch option. Allow the user to start Antigravity without restoring workspace state (no open tabs, no editor memory), similar to VS Code’s --disable-workspace-trust or browser safe modes.

P2 — Improve diagnostics

  1. Surface the failure visibly. If the agent backend cannot initialize or the StreamAgentStateUpdates stream fails, show an error banner in the chat pane — e.g., “Chat is unavailable. A conversation file may be corrupted. [View Details]”. Do not render a normal-looking input box that silently drops all messages.
  2. Log the specific file path that causes the deserialization failure more prominently (currently buried in ls-main.log), and consider writing to a user-accessible error log.
  3. Add crash/error recovery UI. If the previous session ended abnormally, offer to start fresh without restoring tabs (similar to Chrome’s “Restore pages?” prompt).

Workaround (Manual — not feasible for typical users)

The issue was resolved by:

  1. Restoring the old %APPDATA%/Antigravity backup (to preserve the conversation index/history).
  2. Deleting the specific workspace state folder (User/workspaceStorage/<workspace-hash>/) that contained the open-tab reference to the corrupt file.
  3. Deleting the corrupted .pb files from .gemini/antigravity/conversations/.
  4. Killing lingering antigravity.exe zombie processes via Task Manager.

This required custom Node.js scripts querying internal SQLite databases and deep familiarity with the internal file structure. No normal user would be able to do this.

Key Source Files for the Engineering Team

Based on log analysis, the relevant code paths are:

  • cascade_manager.go:539 — Trajectory load failure (no error recovery)
  • interceptor.go:74 — StreamAgentStateUpdates gRPC handler (breaks globally on single conversation failure)
  • log.go:398 — JSON deserialization of corrupt data
  • Workspace state persistence — memento/workbench.parts.editor key in state.vscdb

Submitted by a user after ~6 hours of debugging with AI agent assistance across multiple sessions.

3

Facing the same issue here. I’m surprised this isn’t a more widespread issue that hasn’t been resolved yet, given it used to happen with the older Antigravity as well (pre-2.0/IDE). It heavily affects my ability to be productive, since my conversations can completely disappear from one session to another due to the corruption of these files.

For others facing this issue, the work done by Antigravity Conversation Fix temporarily re-indexes the conversations, but due to the underlying bug being one with the source code of Antigravity, the corruption is prone to happen again eventually. The script also doesn’t perfectly manage to fully restore the conversation metadata (tested on IDE 2.1.1), so after running the script, you still have to figure out which conversation is which by using their IDs and then re-open them in their corresponding workspaces for Antigravity to properly fully rebuild their metadata to be visible in the conversation picker and the sidebar.

I’d urge the Antigravity team to look into this ASAP, since losing your conversation history across the IDE/2.0 really harms the ability of developers to iterate on their work with agents.

4

Hi @John_McLean, Welcome to the Forum!

I wasn’t able to reproduce this issue. Could you please share:

  • Which Antigravity version are you using?
  • Which AI model was selected when the issue occurred?
  • Which operating system are you using (Windows/macOS/Linux)?
  • Did the conversation disappear from Chat History, or was it still visible there?
  • If it was visible in Chat History, could you open it? If yes, what happened when you sent a new message?
  • Does this happen with only one conversation or with all conversations?
  • If possible, Can you provide a reproducible sequence of steps that consistently triggers the issue?
5

Hello @Ambati_Rajendra, sorry for chiming in instead of John, but I feel like I could clarify a few of the questions you had asked. But if @John_McLean has any further corrections or clarifications to add my my response, please feel free to.

  1. I’ve been facing this issue on every latest version of Antigravity, up to the last update before the 2.0/IDE split, and now even on Antigravity IDE 2.1.1.
  2. The AI model was on Gemini Flash 3.5 Flash (High).
  3. Windows. I’ve experienced the issue working natively within Windows, while remoted into a machine through SSH, and while connected to WSL.
  4. The conversation disappeared from chat history (conversation picker),and neither was it visible in the little window of conversations you’ve had in the current workspace that appears right above the chat box.
  5. This happens with all conversations. Almost as if one corruption in the index breaks the entire thing and the IDE window chooses not to render any of the chats in the conversation picker.
  6. Unfortunately ‒ similar to what John mentioned in the ‘Steps to Reproduce’ section of the original post ‑ I cannot give you a reproducible set of steps, either. The loss of chats seems to be tied to an unexpected shutdown of the application.

Perhaps you can look into a more error-proof way of serialising and deserialising the protobuf arrays in which the conversation histories are stored. I would also suggest looking into the Antigravity Conversation Fix repository, as the script on there was written purely as a temporary solution for people facing this issue, and you can tell by the age of the repository that this has been a bug plaguing Antigravity users for a while.