Migrating Antigravity Agent Sessions Across Google Account Logins

Thu, 03 Sep 2026 14:00:00 +0200

When you use an autonomous AI pair programmer like Antigravity on a daily basis, your conversation sessions quickly become your primary engineering journal. Over several months, my local instance accumulated 23 deep conversations across 10 distinct projects—spanning everything from a 5,800-turn Homelab Docker deployment to complex vLLM cluster setups on Google Cloud and day-to-day scripting.

Originally, my Antigravity instance was authenticated with my personal Google account (with an AI Ultra license). When I needed to switch Antigravity to log into a dedicated corporate Google Cloud Project under the Gemini Enterprise umbrella, I hit an unexpected wall: all historical Antigravity sessions were locked to the previous login identity.

The Technical Root Cause: Thought Signatures and the HTTP 400 Error

When you try to resume an existing Antigravity session under a new account login, the failure is immediate. The agent initializes, reads the prompt, and crashes within a second with a fatal backend error:

`1`	`INVALID_ARGUMENT (code 400): Invalid thought signature. HTTP 400 Bad Request`

To understand why this happens, you have to look at how modern Gemini reasoning models handle agentic tool use under the hood:

1. The Role of Thought Signatures (`thought_signature`)

In autonomous coding environments like Antigravity, the model constantly plans and invokes tools (terminal execution, file viewing, code edits). When a thinking model decides to trigger a tool, it pauses its internal chain of thought.

As documented in Google Cloud Vertex AI Function Calling and Google AI Thinking Documentation, the model generates an encrypted cryptographic token called a thought_signature and attaches it directly to the functionCall block. This signature acts as an encrypted save-state: it encapsulates the exact reasoning context and justification that led to the function invocation.

2. Mandatory Echoing and Server-Side Validation

When Antigravity executes the tool locally and sends the result (functionResponse) back to Google’s backend, the API strictly enforces that the entire preceding turn—including the exact, unaltered thought_signature—is echoed back.

If the signature is missing, modified, or signed under a different context, the model’s backend rejects the payload immediately with INVALID_ARGUMENT (code 400).

3. The Account and Boundary Mismatch

Here is the catch: thought signatures are cryptographically bound to the active authentication session and tenant environment.

In the original setup, our conversations were created under the initial personal/Workspace account login. Every tool call in the 23 projects was signed by that account’s endpoint session keys.
When we switched Antigravity to log into the corporate Google Cloud Project, the agent sent the existing chat history (containing the old signatures) to the enterprise endpoint.
The enterprise API refused to validate cryptographic reasoning states generated by an external, non-enterprise account.

4. Enterprise Compliance and Tenant Isolation

This strict rejection is an intentional security mechanism rather than a bug. Under Google Cloud’s Gemini Data Governance, Gemini Enterprise enforces strict tenant boundaries, zero model training on customer data, and independent encryption keys (including Customer-Managed Encryption Keys / CMEK and VPC Service Controls).

Allowing unverified reasoning states from an external account to be injected into an enterprise compliance perimeter violates enterprise isolation guarantees. Once you switch your account login, existing live sessions cannot cross that cryptographic boundary.

Why Simply Copying Folders Fails

The obvious workaround is trying to copy or rename the local brain/ directory:

While local files (transcript.jsonl, artifacts, task graphs) reside on your disk under ~/.gemini/antigravity/brain/<id>/, the backend session state does not belong to the new account.
Duplicating or moving folders does nothing to re-sign historical thought_signature tokens. When the agent attempts the next turn, the API still rejects the legacy payload.

We did not need to keep struggling with broken session handles. We needed our active configurations, verified commands, and project status operational under the new login.

The Solution: Extraction, Distillation, and Context Seeding

Instead of trying to force incompatible sessions across enterprise boundaries, I built a dedicated migration pipeline (extractor_engine.py) to systematically extract, clean, and re-seed our engineering state.

Here is the four-step workflow that migrated all 23 conversations across our 10 projects without losing a single piece of context.

1. Parsing Local Trajectories Directly from Disk

Because Antigravity logs every user prompt, model plan, and tool invocation into structured JSON Lines (transcript.jsonl), we can parse the exact trajectory programmatically without touching any web UI.

We wrote a Python script to scan all conversation directories in ~/.gemini/antigravity/brain/, extract the user requests, and map them to their parent projects:

import json
import re
from pathlib import Path

def clean_user_content(raw_content: str) -> str:
    """Extract clean user prompts, stripping internal XML tags."""
    match = re.search(r"<USER_REQUEST>(.*?)</USER_REQUEST>", raw_content, re.DOTALL)
    if match:
        return match.group(1).strip()
    return re.sub(r"<[^>]+>", "", raw_content).strip()

def parse_transcript(transcript_path: Path):
    """Extract ordered user steps and agent actions from transcript.jsonl."""
    turns = []
    with open(transcript_path, "r", encoding="utf-8") as f:
        for line in f:
            entry = json.loads(line)
            entry_type = entry.get("type")
            content = entry.get("content", "")
            
            if entry_type == "USER_INPUT":
                prompt = clean_user_content(content)
                if prompt:
                    turns.append({"role": "user", "text": prompt})
            elif entry_type == "PLANNER_RESPONSE" and content:
                turns.append({"role": "assistant", "text": content.strip()})
    return turns

2. Distilling the “Golden State”

Copying 5,800 turns of raw conversation into a new enterprise session would be a terrible idea. It wastes context window tokens, inflates costs, and confuses the model with outdated debugging dead-ends and resolved bugs.

Our extraction engine filtered the conversations into two distinct tiers:

Full Transcripts (<Project>_full.md): A complete chronological archive of every prompt and response, preserved for auditability and reference.
Executive Summaries (<Project>_summary.md): A concise breakdown extracting only the resolved architecture:
- Primary goals and requirements
- Generated artifacts and configuration files (docker-compose.yaml, scripts, systemd units)
- Final operational state (IP addresses, open ports, reverse proxy rules)

3. Integrating with a Central Knowledge Base (Obsidian)

The distilled summaries were exported directly into our local Obsidian vault (wojcieh_vault), creating a permanent, searchable layer of engineering memory.

By externalizing the knowledge into versioned Markdown files, the project context ceased to be an ephemeral chat log locked inside an AI tool. It became durable engineering documentation that lives independently of any specific AI model or billing account.

4. Generating Context Seeds for Gemini Enterprise

To make the transition seamless, the migration engine automatically generated a standardized Context Seed block at the end of each summary:

## Context Seed (Prompt for new Gemini Enterprise session)

Continue the project 'Homelab', task: 'Docker Infrastructure'.
- Previous Session ID: 5eee075d-86e8-4006-9942-2d3d169c2d4d
- Total Historical Turns: 5,817
- Active Stack: Traefik double-proxy, Pangolin tunnel, SOPS with Age
- Host IP: 192.168.250.2
- Documentation: `02 Infrastructure/Homelab/Docker_summary.md`
Adopt this context and confirm readiness to proceed.

When opening a brand new Antigravity session under the Google Cloud Project with Gemini Enterprise, pasting this 8-line snippet brings the assistant up to speed in under 10 seconds. The model receives 100% accurate context of where the infrastructure stands, without any token bloat or subscription conflicts.

Key Takeaways

Migrating your agentic pair programmer to a corporate Google Cloud environment brings major benefits—compliance guarantees, enterprise quotas, and centralized project billing. However, account identity boundaries mean your historical conversations cannot simply be re-linked.

If you are planning a similar migration:

Do not rely on live session resumption: Antigravity sessions are tied to the account authentication context under which they were created.
Leverage local state: The biggest strength of a tool like Antigravity is that its brain state lives locally on your disk. You own the logs (transcript.jsonl), which makes custom extraction straightforward.
Distill before re-seeding: Never dump raw historical transcripts into a new LLM session. Filter for the golden state, document it in Markdown (Obsidian/Git), and seed your new enterprise sessions with concise architectural briefs.

Treat your AI chat sessions as disposable working scratchpads. When you externalize decisions and configurations into version-controlled Markdown, switching account logins or AI providers becomes a routine maintenance task rather than a data loss event.

Data Migration on Wojciech Marusiak IT Blog