fix(providers): keep Antigravity catalog static

[luvs01]

Summary

• Complete the static-catalog behavior for the built-in google-antigravity preset already present on dev, so catalog reads, connection checks, settings, and OAuth reconciliation no longer issue or imply unsupported generic discovery.
• Migrate legacy Antigravity configs once. The old GUI and manual edits persisted the same bare liveModels: true with no source metadata, so every ambiguous pre-marker true is normalized once; users who deliberately forced discovery can re-enable it afterward, and later overrides persist through re-login.
• Make the provider settings UI send a sparse PATCH so saving an unrelated field does not silently materialize or change liveModels.
• Return static catalog rows and clear stale discovery failures before OAuth token resolution, so catalog reads neither refresh credentials nor touch the network.
• Keep omitted, explicit-live, and explicit-static provider settings distinct in the catalog single-flight key, preventing concurrent static and live gathers from sharing the wrong result.
• Return a neutral not applicable result for static-catalog connection checks before credential resolution or network access; render it neutrally in the dashboard and CLI, and invalidate stale probe state when provider configuration or active authentication changes.
• Add focused catalog, management API, connection-probe, migration, UI, and concurrency coverage, plus synchronized provider documentation in five locales.

Follow-up to #723. The registry flag itself is already on dev via c4b83693d; this PR carries the remaining reconciliation, settings, catalog-flight, GUI, CLI, test, and documentation work.

Safety review

• This is a provider configuration and availability fix, not a security-vulnerability report.
• No inference, quota, OAuth endpoint, credential format, token destination, or authorization policy changes.
• Both catalog reads and static-catalog connection checks return before OAuth token resolution and are covered by zero-network-call regressions. The neutral response asserts no successful connectivity and cannot expose or forward credentials.
• Pre-marker liveModels: true provenance cannot be recovered from the stored config. The one-time reset is deliberate and version-bounded; a post-migration explicit true remains supported and retains the previous authenticated discovery behavior.
• A targeted auth-boundary and diff review checked credential exposure, unsafe defaults, migration provenance, and concurrent catalog isolation. No blocking security issue was found; a broader security scan was not warranted for this scope.

Verification

Current head fa6b3ef2 is rebased onto current dev (33caf336).

• git range-diff confirms that all five rebased commits are patch-equivalent to the reviewed series; the duplicate registry line already on dev is absent from the final PR diff.
• Bundled Bun 1.3.14 (0d9b296a): root provider/catalog/config regressions 289 passed, 0 failed; rendered GUI regressions 8 passed, 0 failed; typecheck and privacy scan passed.
• Configured Bun 1.4.0-canary.1 (b22e0e6d0): the same root 289/0 and GUI 8/0 suites passed; typecheck and privacy scan passed.
• GUI lint and production build passed; docs build produced 146 pages; git diff --check passed.
• Cross-platform CI 30626272772 is green on Ubuntu, macOS, Windows, and all three npm-global jobs. React Doctor, target enforcement, PR labeling, and CodeRabbit also passed.
• The explicit security approval remains associated with current head fa6b3ef2. The older functional CHANGES_REQUESTED review remains for the maintainer to dismiss or re-review; both maintainers are already requested reviewers, so no duplicate ping was added.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive boundaries were reviewed for secrets, auth, and unsafe defaults.

Summary by CodeRabbit

• New Features

  • Added an Antigravity migration marker to validate and control adoption of the static six-model catalog.

• Bug Fixes

  • OAuth provider reconciliation now consistently forces and persists the Antigravity static-catalog (liveModels: false) behavior, even after migrations and updates.
  • Provider settings saving no longer emits unrelated liveModels changes.

• Documentation

  • Updated the Providers guide (multiple languages) with clearer Antigravity static-catalog notes.

• Tests

  • Added/updated regression, connectivity, and reconciliation tests to ensure no live /models fetching and correct liveModels behavior.

[coderabbitai]

📝 Walkthrough

Walkthrough

Google Antigravity is configured as a static-catalog provider. OAuth reconciliation and configuration migration establish this default while preserving explicit overrides, model discovery skips unsupported requests, UI updates preserve toggle provenance, and tests and localized documentation cover the behavior.

Changes

Google Antigravity static catalog

Layer / File(s)	Summary
Registry and OAuth migration src/providers/registry.ts, src/oauth/index.ts, tests/oauth-provider-reconcile.test.ts, tests/provider-registry-parity.test.ts	The registry sets liveModels: false; reconciliation migrates legacy rows, seeds missing values, and upsert preserves explicit overrides.
Static catalog migration marker src/types.ts, src/config.ts, tests/config.test.ts	A literal version marker is added to configuration, with tolerant loading and validation coverage for malformed values.
Static discovery short-circuit src/codex/catalog/provider-fetch.ts, tests/codex-catalog.test.ts, tests/provider-connection-test.test.ts	Static providers return configured models before OAuth or upstream discovery, clear stale failures, and avoid network requests.
UI provenance and provider guidance gui/src/components/provider-workspace/ProviderSettings.tsx, gui/tests/provider-settings-live-models-provenance.test.tsx, tests/google-models-listing.test.ts, docs-site/src/content/docs/.../guides/providers.md	Settings patches include liveModels only when changed, explicit live-discovery behavior remains covered, and localized guides describe the maintained six-model catalog.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ProviderRegistry
  participant OAuthConfig
  participant fetchProviderModels
  participant ManagementAPI
  ProviderRegistry->>OAuthConfig: set or seed liveModels=false
  OAuthConfig->>fetchProviderModels: provide static provider configuration
  fetchProviderModels->>fetchProviderModels: clear discovery failure
  fetchProviderModels-->>ManagementAPI: return configured six-model catalog
  ManagementAPI-->>OAuthConfig: expose liveModels=false without discovery status

Loading

Possibly related PRs

• lidge-jun/opencodex#354: Modifies live model discovery and discovery-status handling.
• lidge-jun/opencodex#358: Changes static-provider discovery-failure handling.
• lidge-jun/opencodex#406: Changes model fetching and parsing in the same discovery pipeline.

Suggested reviewers: lidge-jun, ingwannu, wibias

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The changes implement #723 by marking google-antigravity static, clearing stale discovery failures, and adding coverage for provider and connection behavior.
Out of Scope Changes check	✅ Passed	The docs, tests, config marker, and GUI patch tweaks all support the static-catalog migration; no unrelated work stands out.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: keeping the Antigravity provider catalog static.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ddf59d03e1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/codex/catalog/provider-fetch.ts (1)

82-124: 🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Build the in-flight key from the effective provider configuration.

At Line 85, a persisted provider with liveModels: undefined and one with liveModels: true both fingerprint as live: true. However, Lines 675-676 enrich persisted providers from the registry, so an old Antigravity config missing the field becomes static while an explicit true config remains live. If their gathers overlap, Lines 641-650 can join the wrong promise: either suppressing discovery for an explicit live override or issuing unsupported discovery for the legacy static config. Authentication state and other catalog-affecting settings are similarly absent from the key.

Compute the key after applying registry defaults to cloned providers, and include all behavior-affecting inputs. Use a non-secret credential generation/digest or explicit invalidation on credential changes; never place raw OAuth/API tokens in the key.

Also applies to: 641-650

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/codex/catalog/provider-fetch.ts` around lines 82 - 124, The in-flight key
must reflect effective provider behavior rather than raw persisted
configuration. Update gatherFlightKey and its callers around provider catalog
gathering to clone providers, apply the same registry defaults used near the
provider enrichment flow, and include every catalog-affecting setting, including
authentication state via a non-secret credential generation or digest (never raw
tokens). Ensure credential changes invalidate or differentiate the key so
overlapping gathers cannot share an incompatible promise.

Source: Path instructions

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@src/codex/catalog/provider-fetch.ts`:
- Around line 82-124: The in-flight key must reflect effective provider behavior
rather than raw persisted configuration. Update gatherFlightKey and its callers
around provider catalog gathering to clone providers, apply the same registry
defaults used near the provider enrichment flow, and include every
catalog-affecting setting, including authentication state via a non-secret
credential generation or digest (never raw tokens). Ensure credential changes
invalidate or differentiate the key so overlapping gathers cannot share an
incompatible promise.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: f71b64f0-97e2-46cc-94a2-421f421c14a6

📥 Commits

Reviewing files that changed from the base of the PR and between ddf59d0 and baea76f.

📒 Files selected for processing (13)

• docs-site/src/content/docs/guides/providers.md
• docs-site/src/content/docs/ja/guides/providers.md
• docs-site/src/content/docs/ko/guides/providers.md
• docs-site/src/content/docs/ru/guides/providers.md
• docs-site/src/content/docs/zh-cn/guides/providers.md
• src/codex/catalog/provider-fetch.ts
• src/oauth/index.ts
• src/providers/registry.ts
• tests/codex-catalog.test.ts
• tests/google-models-listing.test.ts
• tests/oauth-provider-reconcile.test.ts
• tests/provider-connection-test.test.ts
• tests/provider-registry-parity.test.ts

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/oauth/index.ts`:
- Around line 586-588: Preserve existing explicit liveModels: true values unless
reliable legacy-default provenance proves they were implicitly materialized.
Update the migration logic in src/oauth/index.ts lines 586-588 and re-login
handling at lines 682-686 to avoid resetting or marking unproven true values;
update tests/oauth-provider-reconcile.test.ts lines 44-80 and 104-152 to verify
pre-marker explicit true survives reconciliation while retaining migration
coverage for proven implicit static defaults.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 077c9c97-5cde-4f39-837b-cbf127f84d40

📥 Commits

Reviewing files that changed from the base of the PR and between baea76f and 59d95c0.

📒 Files selected for processing (7)

• gui/src/components/provider-workspace/ProviderSettings.tsx
• gui/tests/provider-settings-live-models-provenance.test.tsx
• src/config.ts
• src/oauth/index.ts
• src/types.ts
• tests/config.test.ts
• tests/oauth-provider-reconcile.test.ts

[lidge-jun]

NEEDS-CHANGES + NEEDS-SECURITY-REVIEW

The discovery half of #723 is solved here. Making the Antigravity catalog static in src/providers/registry.ts and returning configured rows from src/codex/catalog/provider-fetch.ts:378-394 — before resolving an OAuth token or touching the network — stops the unsupported request and clears the stale discovery failure. Preserving post-migration user overrides is handled too.

What is still open is the part users actually complain about. tests/provider-connection-test.test.ts:97-114 pins the Antigravity probe to ok: false with "static catalog only". So the request no longer happens, but the dashboard still tells the user the provider is unavailable while inference and quota are working fine. That is the misleading state #723 reports, and the new test currently locks it in.

Two ways forward, either is acceptable:

• probe authenticated connectivity through the existing Antigravity contract and report the real result, or
• return a neutral result that the dashboard renders as "not applicable" rather than as a failure.

Whichever you pick, please cover the rendered connection-test state, not just the management API response — the bug lives in what the user sees.

Security review also applies. MAINTAINERS.md:33-34 covers credential handling, and :35 adds that a provider preset is a credential-destination change. This PR changes an OAuth preset's discovery behaviour, its migration, and whether a credential gets resolved and sent at all.

What happens next: finish the connection-test behaviour with a regression on the rendered state, then request security review.

---

CI context (shared across the current review round). dev is now at 62e937614. The baseline breakage that made every required check red is fixed: run 30545575865 has macos-latest, ubuntu-latest, and all three npm-global jobs green. The one remaining red is windows-latest, and it is not a test failure — it is a Bun 1.3.14 runtime panic (heap.zig:deleteMin reached through spawnSync with a timeout, triggered by our Windows ACL hardening path). That is a runtime defect being tracked separately, so please do not treat a red windows-latest as a signal about your change. Rebase onto current dev before your next push so your checks run against the repaired baseline.

[lidge-jun]

Formalizing the disposition so it shows on your dashboard.

Blocking: the discovery half of #723 is solved, but tests/provider-connection-test.test.ts:97-114 pins the Antigravity probe to ok: false with "static catalog only". The unsupported request is gone, and the dashboard still tells the user the provider is unavailable while inference and quota work fine — which is the misleading state #723 actually reports. The new test currently locks that in.

Either probe authenticated connectivity through the existing Antigravity contract, or return a neutral result the dashboard does not render as unavailability. Cover the rendered connection-test state, not just the management API response.

This also needs explicit security review under MAINTAINERS.md:33-35: it changes an OAuth preset discovery path, its migration, and whether a credential is resolved and sent at all.

Full reasoning in my earlier comment.

[luvs01]

Addressed the blocking connection-state feedback in 397a7499 after rebasing onto current dev.

• Static-catalog probes now return { applicable: false, reason: "static_catalog" } before OAuth/API-key resolution or network access.
• The dashboard and CLI render that result as neutral Not applicable, not as provider unavailability.
• The rendered UI regression covers the requested state, plus config/auth changes clearing old results and aborting or ignoring late responses.

Author-side security review:

• unknown and disabled-provider guards still run before the neutral branch;
• the neutral result asserts no successful connectivity and sends no credential;
• the UI invalidation key contains only provider/config/auth identity metadata, never raw tokens or API keys;
• stale in-flight results cannot repaint state after provider or active-auth changes.

Validation on the rebased head:

• Bun 1.3.14: API/CLI 26/26 and rendered GUI 5/5;
• Bun 1.4.0-canary.1: rendered GUI 5/5, typecheck, GUI lint/i18n, and privacy scan;
• git diff --check clean.

The broad root suite did not finish within the bounded local run, so the new cross-platform CI remains the broad gate.

[lidge-jun]

Status update: the registry half of this PR is now on dev in c4b83693d, credited to you as co-author.

google-antigravity carries liveModels: false at src/providers/registry.ts, so catalog fetch takes the static branch and management reports discovery as disabled rather than failed. Issue #723 is closed on that basis. The regression test forces a credential-bearing path, because the no-token OAuth fallback short-circuits before any probe and would have made the test pass with the flag removed.

This PR stays open for the rest of it. Diffed against current dev, it still carries 31 files: OAuth reconciliation and provenance, persisted provider settings, sparse PATCH behavior, single-flight routed-model gathering, and the GUI work. That is a maintainer security-review surface per AGENTS.md (credential resolution timing and persisted provider state), which is why I took only the flag and left the rest to review rather than landing it autonomously.

It now conflicts with dev. If you rebase, the registry line is already there — dropping that hunk should shrink the conflict.

Sorry for the split; taking the one-line fix separately was the only way to close #723 without pre-empting the review the rest of this needs.

[Ingwannu]

Security review completed against 69edeab18e2de669bde2cf8ce6306f6d38cede8c.

No blocking security finding was identified.

• Static-catalog handling now returns before OAuth token resolution and before any upstream request, so the change reduces credential exposure rather than expanding it.
• The connection-test path returns a neutral applicable: false result without resolving or sending credentials.
• The GUI invalidation key contains provider/config/auth identity only; no raw token or API key is introduced into cache or flight keys.
• The one-time Antigravity migration and explicit post-migration override preservation are local configuration semantics, not a cross-trust-boundary write.

The remaining single-flight/account-switch concerns are bounded to same-user local catalog freshness and do not expose credentials or create an attacker-reachable privilege boundary. This approval is the explicit security review required by MAINTAINERS.md; it does not dismiss or override another maintainer's earlier change request.

[Wibias]

[shipping-github] Verdict: changes-requested

PR: #744 — fix(providers): keep Antigravity catalog static
Head: 8f19291a on dev (mergeStateStatus: CLEAN)
Linked: none (follow-up to #723)

Usefulness

Yes. Completes Antigravity static-catalog behavior after the registry flag on dev: one-time migrate of ambiguous liveModels: true, sparse GUI PATCH so unrelated saves do not materialize discovery, static catalog path before OAuth/network, neutral applicable: false connection probe (API/GUI/CLI), docs + focused tests.

Bugs / correctness

• Method: bug-review.md — complementary deep (silent_failures / resource_leaks / edge_cases); Bugbot claim verified in-session
• Findings: non-oauth / omitted authMode Antigravity rows got liveModels: false but skipped preset models[] refresh → static catalog could stay stale (src/oauth/index.ts)
• Fixed this session: 8f19291a — also refresh OAUTH_RECONCILE_FIELDS during the one-time Antigravity migration when authMode is omitted/key; test asserts models + defaultModel

Security

• Scope reviewed: authn (oauth reconcile), authz (management provider probe), SSRF/outbound (static path skips network), secrets/config, credential destinations, AI catalog listing (defensive), removed-control leads (oauth guard retained with migration exception; static probe still gated)
• Findings: none confirmed (HIGH). Residual LOW: migration is a one-time product tradeoff on ambiguous true (documented)
• Fixed this session: none security-specific (8f19291a is correctness)
• Ingwannu security APPROVED prior tip; tip advanced after that approval for the migrate fix

Spec / standards

• Spec source: PR body claims 1–7
• Gaps: none material (owner CR for neutral UI addressed in fa6b3ef2; Standards PASS)

Reviews

• Owners/maintainers: lidge-jun CHANGES_REQUESTED on 4cf85895 (obsolete vs tip). Tip uses { applicable: false, reason: "static_catalog" } + GUI not-applicable / muted copy — needs dismiss or re-approve
• Bots: CodeRabbit “preserve legacy liveModels: true” declined with rationale (no provenance; post-marker true preserved); thread resolved. No unresolved review threads

Base / CI

• Behind/conflicts: merged upstream/dev in 49869128; tip current, CLEAN
• Required checks: green on 8f19291a (ubuntu/macos/windows + npm-global + enforce-target + react-doctor)
• Local tip: bun test tests/oauth-provider-reconcile.test.ts tests/provider-connection-test.test.ts + bun run typecheck pass

Gate

Hard blocker for approve-comment / merge-ready: GitHub reviewDecision: CHANGES_REQUESTED from owner on an outdated SHA. Code for that CR is already on tip; cannot clear without owner dismiss/re-review.

Bottom line

Ship-worthy once @lidge-jun dismisses or re-approves after the neutral connection-check fix. Everything else is green (CI, threads, tip sync, own bug/security/spec). Suggested owner ping below in chat for confirmation before posting.

[Wibias]

@lidge-jun Tip addresses the connection-check CR: probe returns { applicable: false, reason: "static_catalog" } (not ok: false), GUI shows not-applicable / muted copy, CLI prints not applicable without failing. Please dismiss or re-approve when you get a chance.