[Bug] Antigravity CLI (agy) fails to persist authentication state in WSL 2 environment

Google Antigravity
,
1

Description

When using the Antigravity CLI (agy) inside a WSL 2 (Windows Subsystem for Linux 2) instance, the authentication session fails to persist. Every single execution of the agy command triggers a fresh authentication prompt instead of maintaining the logged-in state, causing significant friction in the development workflow.

Steps to Reproduce

  1. Open a WSL 2 terminal (e.g., Ubuntu).

  2. Execute the base command: agy

  3. Complete the authentication flow via the browser on the host Windows machine. Then exit.

  4. Run agy again.

  5. The CLI immediately requests authentication again instead of recognizing the active session.

Expected Behavior

The CLI should securely persist the session state within the Linux environment after the initial authentication, allowing subsequent agy commands to run without repeatedly triggering the login prompt.

Environment

  • OS: Windows (Host)

  • Subsystem: WSL 2 (Ubuntu 22.04.5 LTS)

  • Tool: Antigravity CLI (agy)

2

I have the same problem. When I paste the login code from the browser into the Antigravity CLI, it gets stuck on ‘Signing In…’

3

I had the same issue too.

Antigravity itself told me its because WSL is headless and is missing the OS keyring to save the CLI tokens in.

I managed to fix it by installing gnome-keyring.

sudo apt update && sudo apt install -y dbus-x11 libsecret-1-0 gnome-keyring

And then adding this to my .bashrc to start the keyring service

if [ -n "$BASH_VERSION" ]; then
    export $(dbus-launch)
    eval "$(echo "" | gnome-keyring-daemon --unlock)"
    eval "$(gnome-keyring-daemon --start)"
    export SSH_AUTH_SOCK
fi
4

In a headless WSL environment, gnome-keyring creates an encrypted login.keyring file by default. Because there is no graphical display manager (GDM) to unlock it automatically during login, the keyring becomes locked, and your user/root password will not work to open it. This causes the CLI to hang or prompt for an unreachable password on subsequent restarts.

The Solution (Create an Unencrypted Keyring for WSL):
Since WSL runs inside an already secure Windows environment, the easiest fix is to wipe the encrypted keyring and force gnome-keyring to save tokens without an extra password.

  1. Delete the current encrypted files:

    rm -f ~/.local/share/keyrings/*

  2. Completely restart WSL (run this in Windows PowerShell, not WSL):

    wsl --shutdown

  3. Open your WSL terminal again and force initialize an unencrypted keyring:

    gnome-keyring-daemon --unlock <<< ""

  4. Log back.

The CLI will now save your session tokens in a blank-password keyring. It will work flawlessly across WSL restarts without ever asking for a password again.

5

How proud Google is, to make such a low-level mistake

6

Hey All,

This issue has been resolved in version 1.0.1. Please restart the agy to apply the update or manually run the agy update.