[Bug]: agy CLI ignores Agent Platform sign-in credentials preventing normal use of Gemini 4 Carbon through antigravity #34395

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

There is no T3 setup that lists Gemini 4 Carbon for the account you configured:

• The managed agy runtime (1.4.5) predates Carbon. Google hasn't published a newer agy-acp-server: the 1.4.12 and 1.5.x URLs under dl.google.com/agy-extensions/releases/windows/ return 404. So unlike [Bug]: Antigravity provider never lists Gemini 4 Argon (bundled ACP runtime 1.3.0 predates it) #19150 (Gemini 4 Argon), a pin bump can't fix this.
• The agy CLI 1.5.5 (custom binary path, feat(antigravity): support agy CLI as custom binaryPath #32503) does list Carbon, but only for ADC sign-in. With the CLI, T3's Agent Platform settings don't take effect: the instance either runs as the CLI's own keyring account, or uses the machine-wide default ADC file.

T3's own model catalog already has gemini-4-carbon (released 2026-11-10), so the only missing piece is the runtime/auth wiring.

Steps to reproduce

1. Install the agy CLI 1.5.5 and sign in to it once with a personal Google account (this puts a token in the OS keyring).
2. In T3, add two Antigravity instances with Binary path = the agy CLI and Sign-in method = Agent Platform:
   • A (API key): a Vertex API key, a GCP project, location global.
   • B (ADC): a GCP project, location global. Instance environment: AGY_ADC_AUTH=true, plus GOOGLE_APPLICATION_CREDENTIALS pointing at a non-default ADC or service-account file.
3. Start a thread on each instance and check the model list and the account that requests go to.

Expected behavior

Each instance uses the sign-in configured in its settings. When the CLI runtime can't support a sign-in method, T3 says so in the provider settings. It should not report Agent Platform as authenticated while running as a different account.

Actual behavior

A (API key): runs as the personal keyring account.

• T3 passes the sign-in by writing <profile>/antigravity-acp/settings.json ({"auth":{"type":"agent-platform"},"gcp":{...}}), pointing GEMINI_HOME at the profile, and setting GOOGLE_API_KEY.
• agy 1.5.5 doesn't read GEMINI_HOME: the name isn't in the binary, the same finding as [Bug]: Antigravity usage limits show a stale account's quota when the agy CLI is the binary path #34381. It ignores the settings file and the key, and signs in from the keyring (see logs below).
• The provider still shows Agent Platform / Authenticated. It lists the consumer account's models (Gemini 3.8 Flash, Claude 4.6, GPT-OSS) and bills that account.
• Adding GOOGLE_GENAI_USE_VERTEXAI / GOOGLE_CLOUD_PROJECT / GOOGLE_CLOUD_LOCATION changes nothing, and T3 strips those names anyway.
• As far as I can tell, 1.5.5 has no Vertex API-key sign-in at all. Its changelog only documents ADC (AGY_ADC_AUTH) and GEMINI_API_KEY.

B (ADC): the CLI only uses ADC when AGY_ADC_AUTH=true is in the instance environment, which T3 doesn't set or mention. With it, agy authenticates via ADC and lists gemini-4-carbon first. The account and quota project then come from the ADC file: GOOGLE_CLOUD_PROJECT doesn't override them, and the instance's GCP project setting isn't used. Choosing a non-default ADC file per instance is blocked by #30413.

Suggested fix

Scoped to the CLI runtime (harnessPath === null). The managed runtime is unchanged.

1. Agent Platform without an API key: set AGY_ADC_AUTH=true automatically.
2. Agent Platform with an API key: report a configuration error ("Agent Platform API keys aren't supported with the agy CLI; use ADC"), the same way antigravityAuthConfigIssue already does for missing settings. Don't report "Authenticated".

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.1.9-nightly.20261111.4501 (Windows desktop); managed runtime 1.4.5; agy CLI 1.5.5 (installed with WinGet)

Environment

Windows 10 Pro 19045, desktop app. Antigravity authMethod: "agent-platform" on a paid GCP project, tested with both a Vertex API key and ADC.

Logs or stack traces

# Reproduced outside T3: `agy --log-file agy.log acp` with the env T3 builds
# (T3's stripped keys removed, GEMINI_HOME=<profile>, AGY_ACP_FORCE_FILE_STORAGE=1),
# then ACP `initialize` + `session/new`.

# A: Agent Platform + API key (GOOGLE_API_KEY set, settings.json in GEMINI_HOME)
launcher.go:249] Failed to resolve GeminiDir ".gemini": .gemini must be an absolute path: path is not absolute, falling back to default
launcher.go:257] ACP app data directory: C:\Users\<user>\.gemini\antigravity-cli (cliDir="", mode=ccpa)
auth.go:157] ChainedAuth: authenticated via keyring (effective: keyring)
server_oauth.go:221] applyAuthResult: email=<personal account>, authMethod=consumer, quotaProject=
# session/new model options: gemini-3.8-flash, claude-sonnet-4-6, claude-opus-4-6-thinking, gpt-oss-120b-medium

# B: same, plus AGY_ADC_AUTH=true
launcher.go:257] ACP app data directory: C:\Users\<user>\.gemini\antigravity-cli (cliDir="", mode=adc)
adc_auth.go:73] adcAuth: authenticated successfully with quota project <project from default ADC file>, token is non-empty: true
auth.go:157] ChainedAuth: authenticated via adc (effective: adc)
# session/new model options: gemini-4-carbon (current), gemini-4-argon, gemini-3.8-flash, ...

Workaround

Use the CLI as the binary path, Sign-in method Agent Platform without an API key, and AGY_ADC_AUTH=true in the instance environment. Then start one thread: the model list only fills in after the first session, because the health check doesn't call session/new. This only works for the account in the machine's default ADC file (gcloud auth application-default login).