What happened?

On 44029b8 (v0.5.1), the operator-owned ("BYO") Antigravity OAuth client that
README now requires cannot complete the live probe, because
cloudcode-pa.googleapis.com is a private Google API that a normal Cloud
project is not allowed to enable. The provider is unreachable for anyone
without an allowlisted project, and README does not mention this prerequisite.

Sign-in itself works. The probe fails:

$ providers login antigravity-oauth
Google Antigravity OAuth sign-in completed with the operator-owned OAuth client.
The route remains disabled until an explicit live compatibility test succeeds.

$ providers probe antigravity-oauth --live --yes
Antigravity project bootstrap failed (HTTP 403; HTTP 403).

The credential record is written correctly (version: 3, managed_by: codex-router, client pair + refresh token present), so this is not the
"incompatible older record" path.

Calling v1internal:loadCodeAssist directly with the same access token shows
what the two 403s are:

{
  "error": {
    "code": 403,
    "status": "PERMISSION_DENIED",
    "message": "Cloud Code Private API has not been used in project <PROJECT_NUMBER> before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/cloudcode-pa.googleapis.com/overview?project=<PROJECT_NUMBER> then retry.",
    "details": [{ "reason": "SERVICE_DISABLED", "metadata": { "service": "cloudcode-pa.googleapis.com" } }]
  }
}

loadCodeAssist is billed to the project that owns the calling OAuth client.
With the bundled vendor client (0.5.1) that was Google's own allowlisted
project; with a BYO Desktop client it is the operator's project, which does not
have the private API enabled — and cannot enable it:

$ gcloud services enable cloudcode-pa.googleapis.com --project=<PROJECT_ID>
ERROR: (gcloud.services.enable) PERMISSION_DENIED: Permission denied to enable
service [cloudcode-pa.googleapis.com]
- '@type': type.googleapis.com/google.rpc.ErrorInfo
  domain: serviceusage.googleapis.com
  metadata:
    permission: servicemanagement.services.bind
    service: servicemanagement.googleapis.com
  reason: AUTH_PERMISSION_DENIED

servicemanagement.services.bind is a producer-side permission: only
allowlisted consumer projects may bind cloudcode-pa. This was run by the
project owner, through gcloud's own first-party client, so no IAM role the
operator can grant themselves changes the outcome. The Cloud Console route is
also a dead end — cloudcode-pa has no API Library entry, so
/apis/api/cloudcode-pa.googleapis.com/overview?project=… redirects to
/apis/library/… and fails to load.

What I expected

Either:

1. README/INSTALL to state the prerequisite plainly — Antigravity OAuth needs a
   Google Cloud project that is allowlisted for cloudcode-pa.googleapis.com,
   with instructions on how an operator obtains that (Gemini Code Assist
   licence? Antigravity onboarding? something else?) — and the probe to surface
   SERVICE_DISABLED as that specific, actionable message instead of
   bootstrap failed (HTTP 403; HTTP 403); or
2. a documented supported path for operators whose project cannot be
   allowlisted.

Right now the documented flow (create a Desktop client you own → login → probe →
enable) terminates in an unactionable 403 for what I suspect is every user
without a pre-allowlisted project.

Suggested small fix regardless of the answer

loadAntigravityProject() in src/antigravity-project.mjs collapses every
attempt into HTTP <status> strings, so the response body — which contains
Google's exact reason and the activation URL — is discarded. Surfacing
error.status / error.details[].reason (at least for 403 SERVICE_DISABLED)
would have turned an hour of guessing into one line.

Which app do you route through?

Codex

Platform

Windows

Version

44029b8 (package version 0.5.1), Node 22.23.2, Windows 11.

Reproduced with a fresh Google OAuth Desktop app client created per README
§Antigravity, consent screen in Testing with the account added as a test user
(the Google consent step itself succeeds — Signed in).