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

Đang mở
#34,395 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
68/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
google-cloud, typescript

Hướng nghiên cứu

Start by tracing the Antigravity provider settings and runtime auth wiring for the CLI path (harnessPath === null), especially where antigravityAuthConfigIssue handles configuration errors. Check how instance environment variables are passed to agy and how authenticated status is determined. Done means CLI Agent Platform without an API key enables ADC, while an API key shows a configuration error instead of authenticated status.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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 #19150 (Gemini 4 Argon), a pin bump can't fix this.
  • The agy CLI 1.5.5 (custom binary path, #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 #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).

Ngôn ngữ chính
TypeScript
Star
24.8k
Fork
6.4k
Merge trung bình
10 giờ 56 phút
Pull request đã merge (30 ngày)
226

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pingdotgg/t3code

Tất cả issue của pingdotgg/t3code

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.