[Bug]: Antigravity CLI is authenticated but Usage Limits requires legacy acp_token.json #34327

Before submitting

• I searched open and closed issues and checked the related reports listed below.
• I included reproduction steps and evidence from the installed application.

Area

apps/server — Antigravity subscription usage probe; Usage → Limits

Summary

With the official Antigravity CLI configured as the provider's custom executable, T3 reports the provider as ready and authenticated and successfully completes a real model turn. However, Usage → Limits omits Antigravity because the usage probe still requires the standalone ACP runtime's antigravity-acp/acp_token.json file.

The resulting message asks the user to sign in, even though this provider is already authenticated.

Steps to reproduce

1. Install and sign in to the official Antigravity CLI. The affected installation uses agy 1.5.2 on Windows.
2. Enable Antigravity in T3 Code and set its custom executable path to the installed agy.exe:

   {
     "providerInstances": {
       "antigravity": {
         "driver": "antigravity",
         "enabled": true,
         "config": {
           "binaryPath": "C:\\Users\\<user>\\AppData\\Local\\agy\\bin\\agy.exe"
         }
       }
     }
   }

3. Confirm that the provider is ready/authenticated and send a prompt.
4. Open Usage → Limits with All environments / All providers selected.
5. Inspect the provider's cached usageLimits.

Expected behavior

T3 should support subscription-limit retrieval for its supported agy acp executable path, where the CLI/account exposes that information.

If limits cannot be retrieved for this authentication backend, T3 should accurately explain that limitation rather than presenting the absence of a legacy token file as a request to sign in again.

Actual behavior and verification

• agy --version: 1.5.2.
• agy acp --help succeeds.
• T3 provider cache reports status: "ready", auth.status: "authenticated", and auth.type: "oauth-personal".
• A real T3 delegated turn using the Antigravity provider and requested model gemini-3.8-flash-high completed and returned the exact requested text, ANTIGRAVITY_T3_OK.
• Usage → Limits displays Codex but no Antigravity section.
• The T3-owned Antigravity profile has no antigravity-acp/acp_token.json.
• The cached result is:

  {
    "windows": [],
    "unavailable": {
      "reason": "unsupported",
      "message": "Sign in with Google to see Antigravity limits."
    }
  }

Source-to-runtime evidence

Inspection of the installed resources/server.asar shows that makeAntigravityUsageProbe:

1. Builds a fixed token path with path.join(input.profileDirectory, "antigravity-acp", "acp_token.json").
2. Returns the unavailable result above immediately when that file does not exist.
3. Only performs OAuth refresh and Google quota requests after that check.

Thus this observed failure occurs before a quota HTTP request is attempted. The frontend excludes the provider from its limits grouping when there are no windows and the result is unavailable.

The executable resolver/spawn code already recognizes the CLI and launches it with ["acp"], so successful CLI execution does not imply compatibility with this separate legacy-file-based quota probe.

Environment

• T3 Code desktop Beta: installed executable ProductVersion 0.1.8.0.
• Windows x64, OS version 10.0.26200.0.
• Official Antigravity CLI: 1.5.2.
• Authentication: personal Google account (oauth-personal).
• Custom CLI executable; no T3-managed standalone ACP installation.

Related reports and distinction

• feat(antigravity): support agy CLI as custom binaryPath #32503 added custom agy executable support; the observed gap concerns the separate usage probe.
• Discussion feat(antigravity): support native Go `agy acp` (antigravity-cli v1.4.12+) as first-class ACP runtime #28315 (converted from feat(antigravity): support native Go agy acp (antigravity-cli v1.4.12+) as first-class ACP runtime #28313) documents the difference between CLI authentication storage and the legacy ACP token file.
• [Bug]: Antigravity shows token usage only, not limits #16104 tracked the initial absence of subscription limits, before that feature shipped.
• [Bug]: Does not mark the remaining limits with Antigravity #20228 / [Bug]: Antigravity usage limits omit Gemini quotas when retrieveUserQuotaSummary returns only 3p buckets #27473 concern missing quota groups after credential loading and quota requests.
• Antigravity provider session fails to open with Argon 4 Medium after weekly quota reset #32856 also mentions empty limits with a custom CLI, but its main failure was session startup; the maintainer response points to permission-mode compatibility. Here a real turn succeeds.

Investigation boundaries

The exact Windows storage location/backend used by the CLI credentials was not established. No credentials were copied or modified. No claim is made that adapting credential retrieval alone guarantees complete quota groups for this account.

Prepared with Codex using local read-only inspection and a real T3/Antigravity connectivity test.