Repository navigation
[Bug]: Linux Antigravity: Google OAuth succeeds, then setup session/new Internal error is shown as "Google sign-in failed" #9655
Description
Activity
Correcting my own report: the throwaway-cwd theory above is wrong. The empty setup directory has nothing to do with it.
T3's logs only show
Internal errorbecause the setup path passes no request logger. The agent writes its own log to/tmp, and that one names the real failure:RuntimeError: Failed to initialize conversation at ws://localhost:40901/. Stderr: Failed to parse initial message: proto: (line 3:5): unknown field "cascadeid"session/newnever reaches the workspace. It dies whenagy_acp_serverhands its config to thelocalharness_externalbinary from the same archive: the server writes the key as lowercasecascadeid, and the harness only acceptscascadeId. I confirmed this by talking to that harness directly —cascadeIdparses,cascadeidreproduces the error exactly.That value comes from a session id the agent generates itself, so nothing T3 sends affects it, and 1.1.1 is still the current release in the ACP registry. So the
session/newfailure is inside Google's build and cannot be fixed here.What T3 can fix is the part in the title: this error is shown as "Google sign-in failed. Start sign-in again." The token is already written by then, so signing out throws away a valid credential and restarts the loop. #10137 makes a
session/*failure say the sign-in worked and tell the user not to sign out.
Before submitting
This is not #9405 / #9425 (Windows never opens the browser / sign-in URL lost on stderr).
This is not #9624 (browser still does not open after #9425).
This is not #9432 (15s health-check timeout).
On Linux the browser does open and Google does succeed. T3 then fails the post-login catalog probe and maps that to a Google sign-in error.
Area
apps/server (Antigravity setup /
session/new) + provider UI error mappingSteps to reproduce
0.0.39-nightly.20260904.1277(build contains fix(antigravity): forward Google sign-in URLs from browser helper #9425).agy_acp_server1.1.1).http://127.0.0.1:…with “Authentication successful / You can close this window and return to your IDE.”Expected behavior
Provider is signed in. Token is used. Models/catalog load.
Actual behavior
The return-URL box disappears (UI goes to verifying), then immediately:
Google sign-in failed. Start sign-in again.
Reproduced again on 1277 after updating from 1273.
Impact
Blocks Antigravity completely on this Linux desktop. Personal Google OAuth cannot finish setup.
Version or commit
0.0.39-nightly.20260904.1277(5f878d2)AppImage. Managed Antigravity ACP
1.1.1.Environment
oauth-personalLogs or stack traces
From
~/.t3/userdata/logs/server.trace.ndjsonon a fresh attempt after 1277:RpcClient.authenticateSuccess (~15–18s).acp_token.jsonis written.settings.jsonis{"auth":{"type":"oauth-personal"}}.RpcClient.session/newand gets ACP Internal error (~1s).Setup does not use the project folder.
AntigravityDriver.makeDisposableRuntimecreates an empty temp dir (t3-antigravity-setup-*) and runssession/newwith that ascwd. That is the failing call. This prefix is still in the 1277 asar.Health check only runs ACP
initialize, so the provider can stayauth: unknowneven though the token file exists.Workaround
None for Google sign-in. Do not click Sign out / Retry after a “successful” browser login — that deletes the token that was already written. Switching to another provider (Cursor / Grok) is the only way to keep working.
Additional context
#9425, #9510, #9514, #9509, #9647 are already in this nightly (or merged the same day). They cover stderr sign-in URLs, health/startup timeouts, ACP 1.1.1, and resume-after-restart. None of them change the throwaway-cwd
session/newprobe or the Internal-error → “Google sign-in failed” mapping.Suggested fix: do not treat post-auth
session/newInternal error as a Google login failure; and/or run that probe against a real project cwd instead of an empty temp directory.