[DATA LOSS] Session history permanently destroyed after unclean shutdown — no self-recovery mechanism

Google Antigravity
1

Updated Bug Report: as of April 20, 2026 10:23AM EST
Bug Report: Session History Gap After Crash

Title

[DATA LOSS][P1] Sessions disappeared from sidebar after abrupt system restart — data files intact on disk

Summary

After an abrupt macOS system restart (kernel-level power event, not a clean shutdown), ~35 conversation sessions spanning an 8-day window disappeared from the Antigravity sidebar. Sessions older than 10 days and sessions created after the restart are visible. The underlying conversation data files (.pb) and annotation metadata (.pbtxt) are fully intact on disk — the sessions are simply not being listed in the UI.

Environment

  • Antigravity version: Latest (as of April 2026)
  • OS: macOS 15.x, Apple Silicon
  • Workspace: Single-folder workspace

Root Cause Analysis (Reverse-Engineered from Source)

What I investigated

  1. chat.ChatSessionStore.index in state.vscdb — Initially suspected as the root cause. After reverse-engineering the source code in workbench.desktop.main.js (specifically the SBn class, Hti constant, _ca entry builder, and $ad validator), I determined this index is used by VS Code’s built-in chat system, not the Antigravity Agent Manager sidebar. This index is empty across ALL workspace storage databases (not just the affected workspace), confirming it’s irrelevant to the Antigravity session listing.

  2. Annotation files (~/.gemini/antigravity/annotations/*.pbtxt) — Text protobuf files keyed by conversation UUID. All missing sessions have intact annotation files containing correct titles and last_user_view_time timestamps.

  3. Conversation files (~/.gemini/antigravity/conversations/*.pb) — All .pb files for the missing sessions exist with correct sizes (ranging 0.3–31 MB each). File integrity appears intact.

  4. Language server binary (language_server_macos_arm, ~89 MB Go binary) — This is the actual component that manages the session list shown in the sidebar. It references conversations/ in its string table and handles all session I/O.

Probable root cause

The Go language server maintains a session index (likely in-memory or synced server-side) that was partially corrupted or lost during the abrupt shutdown. On restart, it recovered sessions from two sources:

  • Server-side/cloud sync: Older sessions (10+ days) that had been fully synced to the backend
  • Active session creation: New sessions created post-restart

Sessions that existed only in the local index cache (the 8-day gap window) were dropped from the listing mechanism, despite their data files remaining physically intact on disk.

Evidence

Component Status Location
Conversation data (.pb) :white_check_mark: All files intact ~/.gemini/antigravity/conversations/
Annotation metadata (.pbtxt) :white_check_mark: All files intact, titles present ~/.gemini/antigravity/annotations/
Brain artifacts (walkthroughs, plans, etc.) :white_check_mark: All directories intact ~/.gemini/antigravity/brain/
VS Code ChatSessionStore.index :cross_mark: Empty — but confirmed irrelevant workspaceStorage/*/state.vscdb
Sidebar session listing :cross_mark: ~35 sessions missing from 8-day window Managed by Go language server

Reproduction Steps

  1. Have an active Antigravity workspace with 50+ conversation sessions spanning multiple days
  2. Experience an abrupt system restart (kernel panic, power loss, forced reboot — NOT a clean shutdown)
  3. Relaunch Antigravity
  4. Observe: sidebar shows sessions from 10+ days ago and newly created sessions, but sessions from the intermediate ~8-day window are gone
  5. Verify: the .pb and .pbtxt files for missing sessions still exist on disk

Expected Behavior

All sessions with intact .pb files in ~/.gemini/antigravity/conversations/ should be visible in the sidebar after restart, regardless of crash conditions.

Requested Fix

  1. Recovery: Add a re-discovery mechanism to the language server that scans conversations/*.pb and cross-references annotations/*.pbtxt on startup, re-registering any sessions that exist on disk but are missing from the active session index
  2. Preventive: Implement crash-safe session index persistence (e.g., WAL-mode SQLite, fsync before acknowledgment) so the local index survives abnormal termination
  3. User-facing: Provide a “Rebuild Session Index” command (or equivalent) that triggers manual re-scanning of the conversations directory

Workaround

None available. The data files are intact but there is no user-accessible mechanism to trigger re-discovery of orphaned sessions.

Technical analysis performed via source code reverse-engineering of workbench.desktop.main.js (ChatSessionStore class), the Antigravity extension (extension.js), and filesystem forensics of the ~/.gemini/antigravity/ directory structure.

Summary

After an abrupt computer restart, all session history in Google Antigravity’s
sidebar is permanently lost. There is no recovery mechanism — restarting the
app and computer does not restore sessions.

Environment

  • OS: macOS (Apple Silicon)
  • Model: Claude Opus 4.6 (Thinking)
  • Sessions affected: 100+ conversations

Root Cause (Diagnosed)

The session sidebar index is stored in a SQLite database: ~/Library/Application Support/Antigravity/User/globalStorage/state.vscdb

Table: ItemTable

  • Key: chat.ChatSessionStore.index
  • Current value: {"version":1,"entries":{}} — empty (26 bytes)

The abrupt restart caused this index to be flushed with an empty object.
The .backup file (state.vscdb.backup) was also created AFTER the crash,
so it contains the same empty index.

Meanwhile, ALL conversation data remains intact on disk:

  • 100 .pb protobuf files in ~/.gemini/antigravity/conversations/ (~400 MB)
  • 106 brain directories with artifacts in ~/.gemini/antigravity/brain/

The app simply cannot see them because its sidebar index is empty.

Impact

  • Complete loss of sidebar navigation to all historical sessions
  • No automatic recovery — the app does not rebuild the index from .pb files
  • Backup is useless — state.vscdb.backup was written post-crash
  • Affects all users who experience any unclean shutdown (power loss,
    kernel panic, forced reboot)

Expected Behavior

On startup, if chat.ChatSessionStore.index has zero entries but .pb files
exist in the conversations directory, the app should rebuild / re-index
automatically.

Suggested Fix

  1. On startup, detect empty index + existing .pb files → trigger re-index
  2. Write state.vscdb.backup BEFORE modifying the primary, not after
  3. Use WAL (write-ahead log) or journaling for crash-safe writes to the
    session index

Workaround

Currently none. Sessions are gone from the UI permanently. The data exists
on disk but is invisible to the app.