[Feature]: Expose CCA imageGenerationModelIds (gemini-3.1-flash-image) in google-antigravity discovery

[GoldenLoaf24h]

Area

Provider integration — Google Antigravity (model discovery / catalog)

What are you trying to accomplish?

Use the account's live CCA image-generation model (gemini-3.1-flash-image) through OpenCodex after v2.25.0. Since #1897 ("match live agy model discovery"), the discovery parser only publishes CCA agent-catalog rows (agentModelSorts) and drops the imageGenerationModelIds section of the fetchAvailableModels response, so the image model no longer appears anywhere in the picker/catalog.

What prevents this today?

parseAntigravityAvailableModels (src/providers/antigravity-models.ts) deliberately excludes standalone image-generation models — its doc comment states they "are not callable through the CCA agent envelope and must not be published to the Codex catalog". That justifies keeping them out of the chat catalog, but it also makes them invisible everywhere else: the only remaining consumer is the hard-coded CCA_IMAGE_MODEL = "gemini-3.1-flash-image" constant in src/server/images.ts (the /v1/images/generations CCA fallback), which can drift from the live upstream catalog. Before #1897 the model was visible because the old parser injected hard-coded image rows.

What should OpenCodex do?

• Parse imageGenerationModelIds rows from the CCA discovery response and register them as image-only catalog entries (clearly marked, excluded from chat routing), so users can discover and target them through the images data plane; or
• If publishing them anywhere is rejected, document the limitation — and the /v1/images/generations CCA fallback as the supported path — in the provider docs, so users who notice the missing picker entry get an authoritative answer.

Possible implementation

• In parseAntigravityAvailableModels, read imageGenerationModelIds and emit rows flagged image-only (modality metadata marks them non-chat; routing excludes them from text candidates).
• Point the /v1/images/generations CCA fallback at the discovered image row when present, keeping CCA_IMAGE_MODEL as the fallback.
• No adapter change needed for the images path: src/adapters/google.ts already treats the ID as image-capable (IMAGE_CAPABLE_MODELS, responseModalities: ["TEXT", "IMAGE"]).

Example usage or interface

ocx models list google-antigravity
...
gemini-3.1-flash-image    (image-only)

Alternatives or workarounds

• Keep relying on the hard-coded fallback constant (works today for /v1/images/generations, but invisible and can go stale).
• Configure a separate direct Google (AI Studio / Vertex) API-key provider for image-capable chat models.

Additional context

Live reference (2026-08-17, from the #1897 verification): the CCA catalog returns 14 agent rows — gemini-3.7-flash-low/medium/high, gemini-3.6-flash-low/medium/high, gemini-3.5-flash-low/medium/high, gemini-3.1-pro-low/high, claude-opus-4-6-thinking, claude-sonnet-4-6, gpt-oss-120b-medium — with image models listed separately under imageGenerationModelIds.

Checks

• I searched existing issues and documentation.
• I removed secrets and personal data.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[Ingwannu]

The drift concern is valid, but publishing imageGenerationModelIds into the ordinary Codex chat catalog is not a safe contract: those IDs are not callable through the CCA agent envelope, and the Codex catalog has no image-only route type that would prevent a chat turn from selecting them.

The supported user path is already /v1/images/generations, documented under Codex integration, with gemini-3.1-flash-image as the pinned CCA fallback. The acceptable future direction is narrower:

• parse the account-scoped imageGenerationModelIds into a separate images-plane discovery result;
• use a validated discovered image id for the CCA Images fallback, retaining the compiled id as fail-closed compatibility fallback;
• never publish that row as a text/chat model and never let a config-level destination receive the OAuth token;
• cover missing/malformed discovery and account/cache invalidation.

Keeping this open as provider roadmap work under that boundary; picker exposure itself is not planned.