Antigravity 400 "Base64 decoding failed" when a thread with Claude history switches to a Gemini model (ctc_* signatures forwarded as thoughtSignature) #174

Summary

Switching an existing Codex thread to a google-antigravity Gemini model fails with a provider 400 when the thread history contains assistant turns produced by an Anthropic (Claude) model. The Claude reasoning signatures (ctc_...) stored on tool calls are forwarded to Antigravity as thoughtSignature, and upstream rejects them because they are not valid Gemini signatures.

Environment

• opencodex 2.7.27 (npm, Windows x64, bundled Bun runtime)
• Codex App routed through the proxy; providers: openai, anthropic (OAuth), google-antigravity (OAuth, cloud-code-assist mode)

Reproduction

1. Start a Codex conversation on an anthropic/... model and let it make tool calls (so assistant turns carry ctc_... signatures in history).
2. In the same thread, switch the model to e.g. google-antigravity/gemini-3.1-pro-high and send a message.
3. The request fails:

Provider error 400: Antigravity invalid request: Invalid value at 'request.contents[26].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for "ctc_038f26d3f20962bc016a54f0fcfa208190a8ec0f289c2ba211"
Invalid value at 'request.contents[28].parts[0].thought_signature' (TYPE_BYTES), Base64 decoding failed for "ctc_038f26d3f20962bc016a54f10302648190b3c87c814750cad5"
...

Cross-provider switches that tolerate foreign signatures (GPT <-> Claude, Gemini -> others) work fine; only history-with-Claude -> Antigravity/Gemini hits this.

Root cause

isLikelyRealThoughtSignature() in src/adapters/google-antigravity-wire.ts is meant to keep synthetic/foreign values off the wire, but Claude signatures pass both checks:

• the synthetic-id prefix regex (fc|call|msg|rs|...) does not include ctc
• the final character-set check /^[A-Za-z0-9+/_=-]+$/ matches ctc_... strings, since they are hex + underscore

So google.ts attaches them as part.thoughtSignature on functionCall parts, and Antigravity rejects the request at TYPE_BYTES validation.

Suggested fix (verified locally)

Add Anthropic-style prefixes to the rejection list:

export function isLikelyRealThoughtSignature(sig: string | undefined): boolean {
  if (typeof sig !== "string" || sig.length < 16) return false;
  if (/^(fc|call|msg|rs|resp|reasoning|item|ws|tool|func|function)[-_]/i.test(sig)) return false;
  // Reject Claude/Anthropic signatures (`ctc_...`, `toolu_...`, `sig_...`): they are not Gemini
  // thought signatures and Antigravity 400s on them ("Base64 decoding failed").
  if (/^(ctc|toolu|sig|claude|anthropic)[-_]/i.test(sig)) return false;
  return /^[A-Za-z0-9+/_=-]+$/.test(sig);
}

With this patch applied to the installed package:

• isLikelyRealThoughtSignature("ctc_038f26d3f20962bc016a54f0fcfa208190a8ec0f289c2ba211") → false
• a real Gemini base64 signature still returns true
• the mixed-history thread can switch to Antigravity Gemini models without the 400

A more general alternative would be to tag stored signatures with their originating adapter and only replay them to the same adapter family, but the prefix-based rejection is a minimal safe fix for this failure mode.

Happy to open a PR with the change plus a regression test if useful.