GitHub Pull Requests/Actions extensions lose authentication on every restart — root-caused to a startup race condition (Ubuntu 24.04, Snap)

Google Antigravity
,
1

Hi everyone,

I’ve been chasing a persistent bug in Antigravity IDE on Ubuntu where the GitHub Pull Requests and GitHub Actions extensions ask me to sign in to GitHub again every single time I restart the app, even though nothing else about my GitHub setup is broken. After a fairly deep diagnostic session, I’ve managed to isolate the exact mechanism, and I think this is worth flagging to the team directly since it looks like a real bug rather than a local environment issue.

Environment

  • Ubuntu 24.04.5 LTS, X11
  • Antigravity 2.5.5, installed via the Ubuntu App Store (Snap, revision 6, classic confinement)
  • GitHub Pull Requests extension 0.114.3, GitHub Actions extension 0.32.3
  • Git 2.43.0

What’s happening

After signing into GitHub through the Pull Requests panel, the session token is correctly written to Antigravity’s local database (state.vscdb) and survives a full app shutdown perfectly intact. But shortly after the next launch — while the app is just sitting idle, before I’ve touched anything — that token gets silently deleted. From that point on, both extensions show as signed out and the Actions panel throws Cannot fetch github context.

I confirmed this isn’t a shutdown-time deletion: I checked the database right after quitting Antigravity (token still there), then again right after the next launch (token still there), then again a few seconds later with the app just sitting open (token gone). So it’s being deleted during startup, not on close.

Looking at the Output panel’s “GitHub Authentication” channel, the extension logs Reading sessions from keychain... and gets Got 0 sessions about 227ms after the app’s very first log line. That’s suspiciously fast for a Linux secret-storage read, which has to round-trip through D-Bus to the GNOME Keyring daemon — especially under a Snap’s classic confinement, which adds an extra D-Bus proxy hop. My working theory is that the GitHub Authentication provider tries to decrypt the stored session before Electron’s safeStorage backend has actually finished initializing on Linux, the decrypt fails, and VS Code’s core secret-storage self-healing logic treats the now-unreadable entry as corrupted and deletes it outright — rather than retrying.

What I’ve ruled out, so this doesn’t get dismissed as a local config issue:

  • GNOME Keyring itself works fine — confirmed with a manual secret-tool write/read/delete round trip, and separately, gh auth status (the GitHub CLI) authenticates and persists just fine using the same system keyring across restarts.
  • libssl1.1 — installed, no change in behavior.
  • Forcing "password-store": "gnome-libsecret" in argv.json — no change.
  • The encryption.migratedToGnomeLibsecret flag — already true and stable across restarts, so it’s not a re-migration loop.

So the OS-level secret store is demonstrably healthy; the issue is specifically in how (or when) Antigravity’s GitHub Authentication provider reads from it on startup.

Reproduction steps

  1. Quit Antigravity fully, confirm no process remains (ps aux | grep antigravity).
  2. Sign into GitHub via the Pull Requests panel.
  3. Check state.vscdb for a row like secret://{"extensionId":"vscode.github-authentication","key":"github.auth"} — it’s there.
  4. Quit Antigravity fully again. Re-check the database — row still there.
  5. Relaunch Antigravity, don’t touch anything. Re-check the database a few seconds later — row is gone.
  6. Pull Requests and Actions panels now show signed out; Actions logs Cannot fetch github context.

Everything else GitHub-related — the general account sign-in, gh CLI, and git push/pull via a credential helper — is completely unaffected, which is what pointed me toward this being specific to the VS Code github-authentication provider’s read timing rather than anything wrong with GNOME Keyring or my system.

I’ve also filed this through the in-app Feedback tool, but wanted to post here too in case anyone from the team can confirm whether this matches a known issue, or if there’s a workaround I’m missing (e.g. a way to delay extension activation until after safeStorage is confirmed ready). Happy to provide the full state.vscdb query outputs and Output panel logs if useful.

2

Hi @unicreator,

Thank you for the thorough root-cause analysis and state.vscdb trace.

We have logged this startup decryption race in SecretStorageService for the engineering team. In the meantime, here are the recommended ways to avoid this on Ubuntu 24.04:

  1. Use the Official Standalone Linux .tar.gz Build Instead of the Snap Package (Recommended):

    • The Snap package (antigravity-ide-snap) is not an official distribution and adds a Snap confinement/D-Bus wrapper around gnome-libsecret.
    • Please download the official Antigravity IDE (v2.5.5) Linux .tar.gz archive directly from antigravity.google/download (Changelog) so the application communicates directly with gnome-keyring-daemon over native D-Bus while keeping OS keyring encryption enabled.

  2. Runtime Argument (argv.json) Workaround (If Staying on the Snap Package):

    • Open the Command Palette (Ctrl+Shift+P), run Preferences: Configure Runtime Arguments (~/.antigravity-ide/argv.json), and set "password-store": "basic" (or "kwallet5" if using KDE Wallet), then fully quit and relaunch the IDE so startup bypasses gnome-libsecret.