[only21mil]

Problem

When Antigravity's Google sign-in lapses, each prompt in an Antigravity thread tries to open a session five times before the run fails (#16367, reported by markusyeo). Every attempt starts Antigravity again. The report's traces put 14 of the 15 failures at Antigravity's request for browser sign-in, which an ordinary session cannot answer. In the report, three prompts produced 15 failed openings, five in about seven seconds per prompt, while Google's licensing check was already returning HTTP 429. None of those retries can work until the user signs in again.

Change

T3 already recognizes this failure. isAntigravitySignInRequiredError matches the ACP auth-required error and the "Sign in to Antigravity in Settings" error raised when Antigravity asks for browser sign-in. The driver uses it to mark the provider as needing sign-in in Settings.

• ProviderAdapterOpenSessionError gets an optional requiresSignIn: true.
• The ACP adapter sets it when the flavor's new optional requiresSignIn(cause) hook returns true. The Antigravity flavor passes isAntigravitySignInRequiredError.
• ProviderTurnStartService fails the run on the first attempt when the session-open error carries the flag. Before, it handed the error back to the effect worker for another attempt.

The run ends with the same error item main shows after its fifth attempt. Clients show it about two seconds sooner because the run no longer stays working through four more attempts. Every other session-open failure retries as before.

Scope and approval

This fixes the sign-in part of #16367. A maintainer triaged it and left it open for investigation of "licensing/sign-in error classification and retry behavior". The change awaits maintainer review. Choices for maintainers to confirm:

• Only Antigravity opts in. Codex, Claude, Cursor, Grok and OpenCode have no sign-in-required signal at session open today, so they are unchanged. Other ACP flavors can opt in through the same hook.
• The HTTP 429 licensing quota from the report is not classified here. The issue's trace does not show how the quota reaches T3's error types and I could not reproduce it, and a quota calls for a delay, not a stop. That part stays open on Antigravity retries session startup after Gemini Enterprise licensing HTTP 429 #16367.
• The error text stays as it is ("Failed to open antigravity provider session ..."). A clearer sign-in message would be a separate visible change.

Verification

• vp test run src/orchestration-v2/ProviderTurnStartService.test.ts src/orchestration-v2/Adapters/AntigravityAdapterV2.test.ts in apps/server: 40 of 40 pass on this branch. With main's source and the new tests, 2 fail: the adapter leaves requiresSignIn unset, and turn start returns the error to the worker for another attempt.
• The new adapter test checks the flag on a sign-in failure. The new turn-start test checks that a flagged failure ends the run after one open while a retry is still available. The existing test for an ordinary retried failure still passes.
• Clients, main and this branch, one prompt each. Antigravity pointed at a stand-in agent that prints Antigravity's Google sign-in prompt on stderr and logs each launch. On iOS and Android the stand-in ran signed in once first, so the client would list an Antigravity model, then signed out for the measured prompt. On main every client stayed in its working state while the server opened the session five times, about 2 seconds, then showed the failure. On this branch the run failed after one opening, 0.13 to 0.22 seconds after the request, and each client showed the same failure. Web (dev client in a browser), Linux desktop (Electron dev app), iOS 26.5 simulator and Android 16 emulator (Debug builds) all behaved the same way.
• After the failure, the composer still takes text, the send button asks the user to sign in to Antigravity first, and "Open provider setup" opens the Antigravity sign-in settings, as on main.
• vp fmt --check and vp lint on the changed files, and vp run typecheck in apps/server, packages/provider-acp and packages/provider-core: pass.

Not checked:

• A real Antigravity install with a lapsed Gemini Enterprise login. I have no such account; the client runs use the stand-in agent.
• The HTTP 429 quota path.
• Physical phones, Windows and macOS desktop.

Prior PRs

No earlier PR made this change. #24652 by t3dotgg (merged) says when sign-in cannot reach Google, and #21419 by juliusmarminge (open) keeps owner-only sign-in feedback. Both change sign-in messages, not startup retries.

Web, main on the left and this branch on the right, timed from the send. Main shows "Working" for about 2 seconds while it retries; this branch fails after one opening.

Full recording (mp4)

Linux desktop app, 1.0 seconds after the send.

iOS simulator, about 1.1 to 1.2 seconds after the send.

Android emulator, about 1.5 seconds after the send.

After the failure on this branch, sending waits for sign-in, and "Open provider setup" leads to it.

The new tests fail on main: the adapter leaves the flag unset, and turn start hands the error back for a retry.

On this branch, both new tests and the existing retry test pass.

The real adapter against a fake agent that asks for sign-in: main leaves the flag unset, this branch sets it. The "turn start" line is the script's reading of the flag.

Production fix, tests, PR description and images written with Claude Opus 5.5 in T3 Code Nightly.

🤖 Generated with Claude Opus 5.5 in T3 Code Nightly

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — This focused server fix stops redundant Antigravity session-start retries when the provider requires sign-in, while preserving existing behavior for other providers and adding targeted tests. Because it changes authentication-related failure handling on a production path, human review is warranted.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 62245d8
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: b6da915d-70dc-48be-8db3-b8ac22571644

Commits

Reviewing files that changed from the base of the PR and between 6a936b8 and b2e3f5f.

Files selected for processing: 6

• apps/server/src/orchestration-v2/Adapters/AntigravityAdapterV2.test.ts
• apps/server/src/orchestration-v2/Adapters/AntigravityAdapterV2.ts
• apps/server/src/orchestration-v2/ProviderTurnStartService.test.ts
• apps/server/src/orchestration-v2/ProviderTurnStartService.ts
• packages/provider-acp/src/server/adapter.ts
• packages/provider-core/src/server/ProviderAdapter.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 2 remain after this review.

Walkthrough

Antigravity session-open errors can now carry a sign-in-required marker. When the turn-start service encounters that marked error, it skips retrying and settles the run as failed. Tests cover error classification and settlement.

Changes: Antigravity sign-in session handling

Layer / File(s)	Summary
Sign-in-required error marker packages/provider-core/src/server/ProviderAdapter.ts, packages/provider-acp/src/server/adapter.ts	ProviderAdapterOpenSessionError can carry requiresSignIn: true. ACP adapter flavors can classify causes and set that field on the session-open error.
Antigravity error classification apps/server/src/orchestration-v2/Adapters/AntigravityAdapterV2.ts, apps/server/src/orchestration-v2/Adapters/AntigravityAdapterV2.test.ts	The Antigravity adapter uses isAntigravitySignInRequiredError as its classifier. Tests cover browser sign-in, ACP authentication-required, and transport errors.
No-retry settlement apps/server/src/orchestration-v2/ProviderTurnStartService.ts, apps/server/src/orchestration-v2/ProviderTurnStartService.test.ts	The turn-start service settles session-open failures marked as requiring sign-in instead of retrying. A test checks that the run fails and records a provider-error turn item.

Priority: Normal

Estimated code review effort: 2 (Simple) | ~12 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant AntigravityAdapterV2
  participant AcpAdapterV2
  participant ProviderTurnStartService
  AntigravityAdapterV2-->>AcpAdapterV2: provides sign-in error classifier
  AcpAdapterV2->>ProviderTurnStartService: returns session-open error with requiresSignIn true
  ProviderTurnStartService->>ProviderTurnStartService: settles start failure without retry

Loading

Possibly related PRs

• pingdotgg/t3code#21021: Changes Antigravity cold-session startup and the ProviderTurnStartService retry and settlement flow.

Suggested labels: bugfix, size:M

Suggested reviewers: juliusmarminge, macroscopeapp

Merge Risk: Minimal · up to b2e3f

The sign-in-required failure is marked and can end the run without retrying. No merge-blocking issue was identified.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: Antigravity no longer retries session startup when the user is signed out.
Description check		The description includes the required Problem, Change, Scope and approval, and Verification sections. It explains the behavior, implementation, tests, client checks, limitations, and approval status. …
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description includes the required Problem, Change, Scope and approval, and Verification sections. It explains the behavior, implementation, tests, client checks, limitations, and approval status. The issue reference is provided, although a direct link or explicit approval comment is not included.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

thanks @only21mil. your existing sign-in classifier and retry guard are the right fix. i kept your implementation and commit, merged current main, and added coverage for ACP auth-required errors and ordinary transport failures. production remains 15 added lines and one changed retry condition; only a redundant field comment was dropped. the new-main Effect diagnostic needed the same narrow optional-model annotation already used in this test file.

verification at b2e3f5f135d0e80ae4486d90a8351a4d8287ea49:

• main plus the regression tests: 3 fail, 39 pass, for the expected missing classification and retry suppression.
• Blacksmith: 133 focused tests pass across turn startup, Antigravity adapter/auth support, and shared ACP adapter. vp run check:changed passes format, lint, both knip passes, GraphQL validation, 21 affected package typechecks, and 42 tests.
• real web client and server with the repo's ACP agent fixture: the same signed-out prompt launches five processes on main and one on this branch, then displays the existing failure. send requires sign-in; provider setup opens the correct settings; after fixture sign-in a follow-up completes.
• two independent GPT-6.1-Sol source reviews approve this head without findings.

unverified: a real Google account with expired sign-in, HTTP 429 licensing failures, desktop/mobile, macOS and Windows. the fixture drives the actual ACP transport and browser-sign-in classification; it does not prove Google authentication. no client code or contracts changed.

before, main is still working after sign-in is required:

after, the same prompt reaches the existing failure after one launch:

captures use matching prompt and provider data. generated thread ids, titles, timestamps, and git metadata differ. no duration comparison is claimed. uploaded images and full video playback/seek were checked.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified unchanged head b2e3f5f135d0e80ae4486d90a8351a4d8287ea49 on this linux boat vm. main was 8031991591e22d76830e4acf6358c4fd78ffcf60. installed dependencies in both checkouts and ran their dev servers separately, stopping main before starting the pr.

installed the real google antigravity 1.3.0 runtime through settings on both. no mocks, fixtures, stand-in executables, or demo turns. added the real git project through the web ui. started identical signed-out antigravity threads through the supported t3 thread start cli against each running server, then inspected them in chrome with the repo's playwright. the signed-out model picker has no models, so these antigravity prompts used the cli rather than bypassing the web controls.

the real runtime produced Sign in to Antigravity in Settings before you continue. on both. read-only persisted state and runtime traces show:

                            main    pr
AcpAdapterV2.openSession       5      1
startup effect attempt_count  5      1
thread terminal status      failed failed

both clients show the existing session-open failure. the pr's composer still accepts text, send remains blocked for sign-in, and "open provider setup" opens the antigravity account settings. separate real codex gpt-6.1-sol prompts submitted through the web ui completed with READY on main and the pr.

blacksmith ran the existing turn-start, antigravity adapter, and antigravity auth-support suites: 68 tests passed. existing github checks pass or are skipped; none are pending or failing. no source changes or pushes were needed.

runtime command transcript and trace counts

main after five attempts:

pr after one attempt, with the same prompt and provider:

the recording shows typing after failure and opening the real provider setup. it does not compare startup durations. inspected the captures and uploaded recording.

Not verified

an authenticated google account expiring mid-session, successful antigravity reauthentication or generation, and google licensing http 429s. this run exercised a genuinely signed-out runtime, not an expired enterprise subscription. ordinary transient startup retries are covered by the passing existing test, not a real transport outage. native desktop/mobile, macos/windows, relay/tunnel connections, and other providers were not exercised.