[Bug]: antigravity wire session id is derived from first-user text, so it changes when the client compacts history #1297

Client or integration

Codex CLI

Area

Provider adapter

Summary

antigravitySessionId() (src/adapters/google-antigravity-wire.ts) derives the wire session id from a SHA-256 of the first user message text, even when the request already carries a real conversation identity.

The function's own comment states the requirement it has to satisfy: the id must stay stable across every turn, because the replay cache observes thought signatures on turn N's response and re-injects them on turn N+1's request, so both turns must map to the same id.

First-user text does not reliably satisfy that. It is stable only while the first user message survives verbatim in the payload the adapter sees. Once history is compacted, summarised, or trimmed — which long Codex sessions do — the anchor text changes, the derived id changes mid-conversation, and the replay cache stops matching. The symptom is thought signatures silently not being re-injected on continuation turns, which on the Gemini side degrades or 400s exactly where signature replay matters.

Meanwhile the request context often already carries something purpose-built for this: a conversation id, a prompt cache key, or the client thread id.

Expected: prefer a real conversation identity when one is present, and keep the text hash only as a deterministic fallback for clients that send no conversation metadata.

Secondary, lower-severity consequence of text anchoring: two distinct conversations that open with identical text (a template prompt, a slash command, a bare "hi") map to the same session id. The current comment argues this is harmless because the replay cache keys signatures on functionCall identity (name + args) rather than on the id alone. That reasoning holds for collisions, but it does not help the instability case above — a changing id, unlike a shared one, loses the association entirely.

Reproduction

Evidence level, stated plainly: this is a mechanism-level report, not a captured failure. I have not recorded a Codex session where a compaction visibly broke signature replay; I found it while reviewing the adapter and cannot currently produce a deterministic capture. Reporting it because the invariant the code documents for itself is not guaranteed by the value it chose.

The reasoning is checkable without a running provider:

1. Read antigravitySessionId() in src/adapters/google-antigravity-wire.ts. It calls firstUserText(parsed) and hashes the result; with no text it returns a random id.
2. Note the comment above it stating that the id must be identical on turn N and turn N+1 for the replay cache to re-inject signatures.
3. Construct two OcxParsedRequest values representing consecutive turns of one conversation where the earliest user message has been dropped or summarised by the client, as history compaction does. firstUserText returns different strings, so the derived ids differ, so a signature cached under turn N's id is not found under turn N+1's.
4. The same holds trivially for the textless case, where the fallback is -${Math.floor(Math.random() * 9e18)} — a fresh id on every turn by construction.

Observable path on a live install, for whoever can hold a long enough session:

1. Configure a google-antigravity provider (adapter: google, googleMode: cloud-code-assist).
2. Run a Codex session with tool calls until the client compacts history.
3. Compare the wire session id sent before and after compaction; then check whether thoughtSignature values observed pre-compaction are still replayed after it.

Suggested fix — prefer, in order, any non-empty conversation identity already on the request, then fall back to the current behaviour:

const stableContextId = [
  parsed.context.conversationId,
  parsed.context.promptCacheKey,
  parsed.options.promptCacheKey,
  parsed._clientThreadId,
].find((v): v is string => typeof v === "string" && v.trim().length > 0);
if (stableContextId) return stableSessionId(stableContextId);

// unchanged fallback for clients that send no conversation metadata
const text = firstUserText(parsed);
if (!text) return `-${Math.floor(Math.random() * 9e18).toString()}`;
return stableSessionId(text);

conversationId / promptCacheKey are not on OcxContext today, so this also needs them threaded from the request context — in my local build that meant populating them in src/server/responses/core.ts from x-codex-parent-thread-id and the existing prompt cache key.

I have been running this shape locally since 2.10.x across antigravity routes without regression, but I want to be clear that "no regression observed" is weaker evidence than a captured failure, and I am not claiming the latter.

Version

2.11.0

Operating system

Windows 11 Home Single Language 26H2 (build 10.0.26200)

Provider and model

google-antigravity / gemini-3.6-flash, claude-opus-4-6-thinking

Logs or error output

No captured failure log — see the evidence note in Reproduction.
The report is based on reading src/adapters/google-antigravity-wire.ts
against the stability invariant its own comment states.

Screenshots and supporting files

Not attached.

Redacted configuration

{
  "providers": {
    "google-antigravity": {
      "adapter": "google",
      "baseUrl": "https://daily-cloudcode-pa.googleapis.com",
      "authMode": "oauth",
      "googleMode": "cloud-code-assist",
      "defaultModel": "gemini-3.6-flash"
    }
  }
}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.