[Bug]: Antigravity Gemini Enterprise (oauth-business): session/new never answers after successful authenticate, and sign-in blames the network #29379

Summary

With sign-in method Gemini Enterprise, initialize and authenticate succeed, but session/new never returns a response and no error is emitted. T3 then interrupts it at the 5-minute sign-in deadline and reports a network problem, although Google was reached. The hang also reproduces without T3 when the ACP runtime is driven directly, on runtime 1.4.1 and 1.4.5.

Area

apps/server, managed Antigravity ACP runtime

Environment

• Windows 11 Enterprise (10.0.26100), x64
• T3 Code 0.1.6 desktop
• Managed runtime agy_acp_server 1.4.1; 1.4.5 tested separately
• Auth method oauth-business, tier gcp-ge-plus-tier (Gemini Enterprise Plus)
• GCP location eu and global, both offered by the license picker

Steps to reproduce

1. Settings > Providers > Antigravity > Sign-in method: Gemini Enterprise, with GCP project and location set.
2. Click Sign in and wait about 50 s for Open browser.
3. Complete Google login and the license picker until the page shows "All set!".
4. Return to T3 and wait.

Expected behavior

The session opens. If the runtime stops responding during session/new, T3 reports that phase instead of a network problem.

Actual behavior

Shown after 30 s, during normal startup:

Antigravity has not reached Google after 30 seconds. Check this machine's network connection. Broken IPv6 is a common cause.

Shown after the 5-minute deadline:

Antigravity could not reach Google. Check this machine's network connection, then start sign-in again.

Evidence from server.trace.ndjson

Each session/new span ends with InterruptError: All fibers interrupted without error at AntigravityAuth.runSignIn. Each attempt creates a new file in antigravity-acp/conversations/, and the ones I checked stay at 0 bytes.

Reproduced without T3

I spawned agy_acp_server.exe directly with the environment from buildAntigravityAcpSpawnInput (GEMINI_HOME, AGY_ACP_FORCE_FILE_STORAGE=1, ANTIGRAVITY_HARNESS_PATH), then sent over stdio:

1. initialize with {protocolVersion: 1, clientCapabilities: {}, clientInfo}
2. authenticate with {methodId: "oauth-business"}
3. session/new with {cwd, mcpServers: []}

authenticate returns:

{"_meta":{"antigravity":{"tier":{"name":"Gemini Enterprise Plus","id":"gcp-ge-plus-tier","upgradeUri":""}}}}

session/new got no response within the wait (up to 150 s), with no error on stdout or stderr. The last stderr line is always:

mcp_servers.py:230] Attempting to load global MCP configs from <GEMINI_HOME>\config\mcp_config.json

Same result on 1.4.1 and on 1.4.5 (official zip, SHA-256 matches antigravityRelease.ts).

During the hang, the two snapshots I took per run showed only the two agy_acp_server.exe processes. Their only TCP connection was a loopback pair inside one process, with no connection to Google.

Variables tested, same hang each time

• GCP location eu and global
• Stored token, and a new profile with a fresh browser login
• mcp_config.json missing, and containing {"mcpServers":{}}
• ANTIGRAVITY_HARNESS_PATH valid, and pointing to a nonexistent file (no error either)
• GOGC=off set for the runtime

Ruled out

• Network: Google endpoints answer over IPv4 in under 0.2 s from the same machine, and no proxy is set. The hostnames do not resolve over IPv6 here, and authenticate succeeds.
• License and account: authenticate resolves the tier, and the Antigravity desktop app works with the same account. The desktop app uses language_server.exe, not this ACP runtime.
• Endpoint security on this machine: the same symptom appeared on a second PC without it, using the same account. On that PC I only observed the behavior in the UI and did not collect traces.

Likely separate issues

1. The misleading message remains after fix(server): Antigravity sign-in no longer blames the network when the runtime never starts #29057. That PR changes the text only when the agent never answers initialize. Here it does answer, so the network message stays.
2. The 30-second hint fires during normal startup. initialize takes 27-43 s on this machine, so NO_RESPONSE_MESSAGE appears on nearly every attempt, shortly before Open browser appears.
3. The paste field cannot work when the local page loads. After the Google redirect, the page continues to the license picker, and code and state disappear from the address bar. The token is already stored by then. T3 keeps showing "If the final localhost page does not load, paste its full URL here", which looks like a required step. This probably explains why pasting failed immediately on my very first sign-in, but I have no logs from that attempt.
4. localharness_external.exe --help crash on 1.4.1. On the machine with endpoint security it failed with fatal error: unknown caller pc, and the stack contained addresses from a security product's DLL. On 1.4.5 it starts normally, and the hang remains, so this is not the cause of the hang.

Not known

• Why session/new hangs. I have no stack dump of the hung runtime.
• Whether the hang is specific to oauth-business. I did not test oauth-personal with this runtime.
• Whether it is specific to Windows.

Requests

1. Can someone with a Gemini Enterprise test account check whether session/new completes on 1.4.5, on Windows and on another OS? Earlier triage on Antigravity retries session startup after Gemini Enterprise licensing HTTP 429 #16367 noted that no such account was available.
2. Should T3 apply a phase-specific message or timeout to session/new during sign-in, so a hang is not reported as a network failure?
3. If this needs to go to Google as a runtime bug, what diagnostics would help? I can run a build or commands on the affected machine and report back.

Related

• [Bug]: Misleading "Broken IPv6" network timeout error shown when Antigravity runtime hangs at startup #29039 and fix(server): Antigravity sign-in no longer blames the network when the runtime never starts #29057: misleading network message when the runtime never answers initialize
• Antigravity retries session startup after Gemini Enterprise licensing HTTP 429 #16367 and [Bug]: Antigravity Google sign-in hides the real failure reason (ineligible account, rejected redirect URL) #17508: other Gemini Enterprise failures, at the authenticate step
• [Bug]: Antigravity sessions fail to open when the browser-suppression preflight exceeds 5 seconds #20529: browser-suppression preflight timeout, seen once here on a first attempt
• Antigravity on Windows: dangling config/skills junction breaks session/new (fix inside) + ZCode provider feature request #27976: session/new failure on Windows from a dangling junction, which returned an error rather than hanging

Impact

Blocks Antigravity completely for this account in T3 Code. The desktop app remains usable.