Fresh triage: this reports a startup reliability bug, not an exploitable vulnerability. On main b5a226e49c, prepareAntigravityProfile still imposes a five-second browser-helper verification timeout. No real-app reproduction was completed. The reported Windows desktop setup is unavailable here, and changing this sign-in helper verification requires maintainer review under the triage authentication hard stop. Leaving this issue open; no fix was written. Duplicate checking found no matching report among 850 open issues through August 27, but the remaining pages failed with ConnectionRefused.
[Bug]: Antigravity sessions fail to open when the browser-suppression preflight exceeds 5 seconds#20529
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
This depends on load, so there is no deterministic repro. Observed sequence:
- Enable Antigravity with Google sign-in (
oauth-personal) and sign in. - While the machine is busy, start an Antigravity delegation. In this case another provider's delegated task was running commands at the same time.
- Opening the session fails after about 6 seconds. T3 retries 5 times over about 30 seconds, and every attempt fails the same way.
- Later, with the machine less busy, the same preflight succeeds in 3,021 ms, and the next one in 100 ms.
Expected behavior
A slow start of the browser-suppression helper does not fail the session. That helper's result depends only on the T3 runtime path, which doesn't change between sessions.
Actual behavior
The session fails with "Provider session failed to open." The trace shows orchestrationV2.providerTurnStart.start → AcpAdapterV2.openSession → AntigravityDriver.makeRuntime → prepareAntigravityProfile failing with AcpTransportError, thrown from the orElse of the preflight's Effect.timeoutOrElse({ duration: "5 seconds" }) (apps/server/src/provider/antigravityAuthSupport.ts:366). The detail is "Antigravity browser suppression verification timed out."
This isn't an expired Antigravity login. The preflight runs before any token is read, and T3's Antigravity profile keeps its own token file, separate from the agy CLI's keyring login.
Impact
Minor bug or occasional failure
Version or commit
v0.1.0 (stable desktop). The same 5-second timeout is on main; since v0.1.0 this file only had comments removed.
Environment
Windows 11 x64, T3 Code desktop v0.1.0, T3-managed Antigravity runtime 1.3.0, oauth-personal auth.
Logs or stack traces
shell
| 1 | # times relative to the first failure |
| 2 | +0:00 prepareAntigravityProfile Failure 6310ms |
| 3 | +0:06 prepareAntigravityProfile Failure 6117ms |
| 4 | +0:12 prepareAntigravityProfile Failure 6323ms |
| 5 | +0:19 prepareAntigravityProfile Failure 5913ms |
| 6 | +0:26 prepareAntigravityProfile Failure 5890ms |
| 7 | +20:33 prepareAntigravityProfile Success 3021ms |
| 8 | +21:50 prepareAntigravityProfile Success 100ms |
| 9 | |
| 10 | AcpTransportError: ACP transport operation failed. |
| 11 | at authSupportError |
| 12 | at Object.orElse |
| 13 | at prepareAntigravityProfile |
Workaround
Retry the delegation once the machine is less busy.
Related
Closed #11767, #12245, #13215, and #13216. Those were the same preflight failing outright for other reasons, not timing out.
Investigated and written with Claude Opus 5.5 in Claude Code.