Summary
This report concerns the official standalone Antigravity ACP server (agy_acp_server / antigravity-acp), not the agy CLI. The primary failure appears to be in the ACP server/session persistence path rather than a generic JetBrains Air UI/restore issue.
Antigravity ACP sessions are persisted and surfaced to the client, but some of those sessions cannot be loaded again. JetBrains Air initializes the official agy_acp_server with session load/resume support, attempts to import an existing session, and then rejects it because session/load replays no conversation history.
The failure is not limited to one session. At least these sessions show the same behavior:
0972ed2b-c2bc-4910-ad29-12c21a4122..
0a8da197-bf7a-4327-a7c5-4753b85222..
For the primary failing session, the persistent database and metadata files still exist under:
~/.gemini/antigravity-acp/conversations
but session/load replays no transcript content.
Environment
Windows 11 26H2 build 26340.9577
Antigravity 2.0 v2.18.1
agy_acp_server v1.2.1
JetBrains Rider 2026.2.3, build RD-262.10968.135
JetBrains Air plugin 262.8665.467
Project: D:\RE_Ecosystem
Steps to reproduce
- Open a project in JetBrains Rider/Air (
D:\RE_Ecosystem). - Use Google Antigravity through the official
agy_acp_server 1.2.1integration. - Create/use an Antigravity ACP session and let it contain conversation history.
- Later refresh Agent Sessions and reopen the existing ACP session.
- Air attempts to import the existing session through
session/load. - The session fails to open.
Actual result
Rider/Air logs contain:
refused to import ACP session ...: session/load replayed no history
Imported ACP session ... replayed no transcript content
cannot import acp.registry.antigravity-acp session ...
The same pattern is recorded for multiple Antigravity ACP sessions.
In the UI, the affected session cannot be reopened and Air reports:
Could not open the session. Try again
Details:
Imported ACP session 0972ed2b-c2bc-4910-ad29-12c21a4122.. replayed no transcript content
Expected result
Because the agent advertises loadSession support, session/load should restore the existing conversation and replay its retained history to the client so that the session can be reopened and continued.
The ACP specification states that an agent supporting session loading must replay the conversation to the client through session/update notifications before completing session/load. This mechanism is specifically intended to support persistence across restarts and reuse of sessions by different client instances. GitHub
Why this appears to be upstream in agy_acp_server rather than a generic Air restore failure
Rider is using the official agy_acp_server 1.2.1 binary.
Persistent Antigravity ACP conversation files exist for the failing sessions.
The Antigravity ACP facade is initialized with loadSession=true and resume=true.
In the same Rider/Air ACP framework, a Codex session successfully imports and logs:
replayed 2 events
while affected Antigravity ACP sessions replay zero history and fail materialization.
Related session discovery/history observations
There also appears to be a broader session discovery consistency problem.
Some Antigravity ACP sessions are persisted but later cannot be reopened. A separate session/list attempt also failed after the ACP provider initialization timed out.
Some imported Antigravity sessions have appeared using generic Session <UUID> style titles. JetBrains support separately confirmed that these titles are passed through from the agy_acp_server session/list response rather than generated by Air.
Sessions created through the standalone Antigravity ACP path are also not consistently visible across Antigravity surfaces/client instances. I understand that the native Antigravity application may use a separate local session store, so I am including this as supporting context rather than claiming that the native app is required to share exactly the same database.
However, for ACP itself, session/list is specifically intended to enumerate sessions known to the agent for history, switching and resume workflows. SessionInfo includes a required sessionId and cwd, with optional metadata such as title and updatedAt. GitHub
It would also be helpful if Antigravity ACP could preserve project association and conversation/thread grouping, so sessions that belong to the same ongoing conversation within the same project are grouped together instead of appearing as unrelated standalone sessions.
Impact
Session history becomes unreliable: a conversation may still exist on disk and be exposed as an existing ACP session, but reopening it can fail because no transcript history is replayed.
This breaks persistence across server/client restarts or rematerialization and makes session history, switching and continuation unreliable for ACP clients.
Attachments
AGY_ACP_DIAGNOSTICS_REDACTED.txt
The attached file is a sanitized extract from the original diagnostic capture. Account/OAuth information, Windows user-specific paths, unrelated process details and verbose non-ACP logs were removed.
I can provide the original full Rider diagnostic log privately if required.