[Bug] sys_list_models reports antigravity-native as having no usable model provider regardless of configuration

Description

sys_list_models reports every antigravity / agy harness spelling as having no usable model provider, on an install where agy is signed in and demonstrably working. No providers: configuration can fix it — including the Gemini API key that the provider layer does resolve correctly (evidence below).

antigravity-native:
  source='none' verified=False models=0
  note='no usable model provider (no model provider configured)
        — dispatches to this worker cannot run here'

This is the same class of false negative as #2236 and #998 (cli-config / cursor-native), which were fixed by short-circuiting CLI-login harnesses to a subscription-style readout. agy has the same shape — it brings its own Google OAuth login, so there is no omnigent-side provider to resolve — but it was not covered by that fix.

Why it matters. An orchestrator preflighting with sys_list_models concludes the worker is dead and drops it. Observed live with polly: it refused to dispatch to agy and reported Antigravity as unconfigured, while a forced dispatch boots and completes normally. omnigent setup simultaneously reports "Antigravity sign-in ready" for the same install, so the two readouts contradict each other.

Nothing actually blocks dispatch, which confirms the readout is the only defect:

• resolve_native_antigravity_launch() returns auth_mode="subscription" unconditionally (its gemini_auth_has_credential() call is documented as informational only)
• the sys_session_send gate uses the provider solely to normalise a model id; kind="none" passes through unchanged

Root cause — two harness→family maps disagree.

model_catalog._PROVIDER_RESOLUTION_HARNESS collapses every agy spelling (agy, antigravity, antigravity-native, native-agy, agy-native, google-antigravity) to the single harness type "antigravity". _provider_harness_name() passes that through unchanged. Then:

• provider_config._HARNESS_FAMILY["antigravity"] → openai
• provider_config._HARNESS_FAMILY["antigravity-native"] → gemini

So the readout asks default_provider_for_harness(cfg, "antigravity"), which looks up the openai-family default, while any Gemini credential is registered under the gemini family. It finds nothing and returns kind="none".

A Gemini API key does not fix it. This is the decisive evidence — the credential resolves under one name and not the other, and the readout only ever asks the failing one:

import os
os.environ["GEMINI_API_KEY"] = "AIza-anything"   # value irrelevant

from omnigent.onboarding.provider_config import load_config, default_provider_for_harness
from omnigent.onboarding.detected import effective_config_with_detected
eff = effective_config_with_detected(load_config())

default_provider_for_harness(eff, "antigravity-native")  # -> gemini   (credential IS found)
default_provider_for_harness(eff, "antigravity")         # -> None     (what the readout queries)
resolve_model_provider(spec, "antigravity-native")       # -> kind='none'  (unchanged)

Second, deeper gap. Even with the mapping corrected, an OAuth-only install (subscription, no API key — the default agy onboarding path) still resolves to nothing. resolve_model_provider consults only the providers: block, ambient GEMINI_API_KEY detection, and legacy auth: blocks. It never calls omnigent.onboarding.gemini_auth, which is the only module that knows about the OAuth token — and which returns True here:

gemini_auth.gemini_auth_has_credential()  -> True
gemini_auth.gemini_login_detected()       -> True
~/.gemini/antigravity-cli/antigravity-oauth-token  present, valid shape, refreshes correctly

Minor related trap: _parse_provider accepts kind: subscription with any non-empty cli:, but only claude→anthropic and codex→openai map to a family. cli: agy therefore parses without error and silently serves nothing, which is a plausible dead end for anyone trying to configure this by hand.

Steps to reproduce

1. Install agy and sign in via the normal browser OAuth flow (no GEMINI_API_KEY anywhere). Confirm omnigent setup → Antigravity shows "Antigravity sign-in ready".
2. Confirm the harness is detected: GET /v1/hosts reports antigravity-native: true.
3. Confirm agy itself works: agy -p "Reply with exactly: OK" → returns OK.
4. Call sys_list_models from any agent declaring tools.agents (e.g. polly), or directly:

from types import SimpleNamespace
from omnigent.model_catalog import resolve_model_provider, list_models_for_worker

spec = SimpleNamespace(executor=SimpleNamespace(
    auth=None, profile=None, config={"harness": "antigravity-native"}, model=None))

print(resolve_model_provider(spec, "antigravity-native"))
# kind='none'  detail='no model provider configured'
print(list_models_for_worker(spec, "antigravity-native").note)
# 'no usable model provider (no model provider configured) — dispatches to this worker cannot run here'

Observed: every agy spelling reports kind='none' and the dead-worker note. Expected: a subscription-style readout — verified: false, note stating the credential is the CLI's to resolve at launch — exactly the behaviour #2236 established for cursor-native and cli-config.

1. Confirm the worker is not actually dead: instruct the orchestrator to dispatch to agy anyway. It boots and completes normally (verified — polly dispatched to both claude_code and agy, both returned correct results; the antigravity-native harness launched the real agy binary in its own tmux pane with an isolated --gemini_dir).

Suggested fix

Mirror the existing cursor short-circuit in _resolve_model_provider_unsafe:

if (harness or "") in _CURSOR_HARNESSES:
    return ResolvedModelProvider(
        kind=SUBSCRIPTION_KIND, cli="cursor-agent", detail="cursor-agent CLI login"
    )

An agy install authenticated by Google OAuth is the same case — the CLI carries its own login and there is no omnigent-side provider to resolve or fail. Gating that branch on gemini_auth.gemini_login_detected() would also close the OAuth-only gap. Separately, resolving the family from the specific harness id rather than the collapsed type would let antigravity-native keep its gemini family for the API-key path.

Version

0.12.0 (built 2026-09-01T20:58:30Z)

OS

Ubuntu 24.04.3 LTS on WSL2 (Windows 11), Python 3.12.3

Harness

Antigravity

Harness mode

Native

Platform or device

Linux (WSL2)

Observed impact

All users or sessions

Authentication type

Subscription / CLI login (Google OAuth via agy)