[Bug]: Every Antigravity (Gemini) turn fails with 400 INVALID_ARGUMENT because t3_theme_set declares a numeric enum (theme.version: {enum:[1], type:"number"})

What happened

Every Antigravity turn fails immediately, whatever the model. I tried gemini-3.8-flash and gemini-4-argon. The thread shows Agent execution terminated due to error. and the CLI reports Antigravity stopped this turn because of an error.

The Antigravity runtime log shows that Google's API rejects the tool declarations T3 sends:

E1114 14:18:08.215560 errorreport.go:273] agent executor error: generating and executing: INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[63].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

It happened again at 14:18:26 on the second thread, with the same message.

Cause

The schema for T3's own MCP tool t3_theme_set, as cached under <userdata>/providers/antigravity/<hash>/antigravity-acp/mcp/t3-code/t3_theme_set.json, contains:

"version": { "enum": [1], "type": "number" }

Gemini function declarations accept only string enum values. The numeric 1 reaches Google as an empty enum entry, so the API rejects the request and the whole turn fails. One unusable tool breaks the provider entirely, not just theme changes.

Steps to reproduce

Enable the Antigravity provider and sign in with Google (status: ready, authenticated).
Start any Antigravity thread, for example:
t3 thread start --provider antigravity --model gemini-3.8-flash --wait <project> "Reply with one sentence."
The turn fails at once, and the Antigravity log shows the 400 above.

Expected behavior

Antigravity turns run normally.

Possible fix

Don't send a numeric enum to Gemini. Either drop the enum from theme.version (validate version === 1 on the server, or make it optional with a description), or declare it as a string enum ["1"]. A more general option is to sanitize T3's MCP tool schemas for Gemini-backed providers by removing or stringifying non-string enum values.

Version

T3 Code 0.1.10-nightly.20261114.4669 (desktop), managed antigravity-acp 1.5.8

Environment

macOS 27.2, Apple Silicon (arm64)

Filed with help from an AI assistant on my behalf.

Just noticed this now too

I tried to reproduce this on the current build and could not.

Commit a472342 (origin/main). An Antigravity/Gemini turn cannot run on this VM: no worker has Antigravity. I reproduced the root cause instead. I added a case to apps/server/src/mcp/advertisedJsonSchema.test.ts that advertises a tool with parameters { theme: { version: Schema.Literal(1) } }, the same shape EnvironmentThemeFile gives t3_theme_set, and asserts that every enum value in advertisedJsonSchema(tool) is a string. vp test run src/mcp/advertisedJsonSchema.test.ts fails on main with expected [ 1 ] to deeply equal []: the advertised MCP input schema contains the numeric enum [1], which matches the reporter's cached t3_theme_set.json and Google's 400 'enum[0]: cannot be empty' error. Pushed as factory/repro-36508 (c63fe9b).

Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.

Still happening on this machine.

Version

T3 Code (Nightly) 0.1.10-nightly.20261114.4669
macOS 27.2.1 (26B131), arm64
Antigravity ACP 1.5.8, signed in with a personal Google account (oauth-personal, consumer)

Steps

New thread on the Antigravity provider, model Gemini 4 Argon.
Send any message. I sent a one-line question, then retried with ..
Both turns stop in about a second. The thread shows Agent execution terminated due to error. and Provider error: Antigravity stopped this turn because of an error.

Same failure on Gemini 3.8 Flash and Gemini 4 Hydrogen. Claude Opus 5.5, Claude Sonnet 5.5, and GPT-OSS 120B on Antigravity still complete a turn.

Log (antigravity-acp/log, 2026-11-14 13:22 local)

E1114 13:22:29.735191 errorreport.go:273] agent executor error: generating and executing: INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[66].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

The retry at 13:22:43 is the same line. The cached t3_theme_set schema on disk is still:

"version": { "enum": [1], "type": "number" }

The unit test on a4723422e7 already fails with expected [ 1 ] to deeply equal [], so current main still advertises that numeric enum. Google rejects it as an empty enum entry, which is why every Gemini turn dies before the model runs. The open fix is #36488.

Note

🤖 Agent responding on behalf of Miles

Reproducing on Windows 11 with the same version. Every Gemini turn fails immediately — same 400, same tool index.

Version

T3 Code (Nightly) 0.1.10-nightly.20261114.4669 (Windows 11, x64)

Log (acp-server-20261114_130013-20268.log, 2026-11-14 13:00 local ICT/+07:00)

E1114 13:00:16.686716     586 errorreport.go:307] agent executor error: generating and executing: INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[66].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty
E1114 13:00:16.691195     586 errorreport.go:307] generating and executing: INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[66].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

Tool index matches the macOS report exactly: tools[66]. Cached schema on disk:

"version": { "enum": [1], "type": "number" }

Gemini 3.8 Flash and all other Gemini models tested fail. Claude and GPT-OSS models on the same Antigravity instance are fine. This is a Windows repro confirming the issue is not platform-specific — the numeric enum reaches Google as an empty entry regardless of OS, so the closed "not planned" state is incorrect. The fix in #36488 is still needed.

Note: tools[66] vs tools[63] in the original report is likely a tool-count difference from different user configurations (number of MCP tools active), not a different root cause.

I am seeing the same failure on Windows, including with managed Antigravity ACP 1.5.9.

Environment:

T3 Code Desktop Nightly: 0.1.10-nightly.20261114.4669
Windows x64, OS build 26300.9974
Managed Antigravity ACP: currently 1.5.9; earlier logs also show the same failure with 1.5.8
Authentication: oauth-personal
Current model reported by the runtime: gemini-4-argon-medium

Sending a message in an Antigravity session stops the turn with "Antigravity stopped this turn because of an error."

The existing runtime logs show the failure on both a new session (session/new, ACP 1.5.9) and a resumed session (session/resume, ACP 1.5.9). On 2026-11-14 at 15:06:26 UTC+09:00, the new session logged:

INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[63].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

The resumed session logged the same error at 15:10:21. Earlier ACP 1.5.8 logs contain the identical error.

The locally cached <userdata>/providers/antigravity/<profile>/antigravity-acp/mcp/t3-code/t3_theme_set.json contains:

"version": {"enum": [1], "type": "number"}

This confirms that the numeric enum and matching runtime error are both present in my installed nightly build, and that the issue persists with ACP 1.5.9. I have not tested other Gemini models or the fix in #36488.

The environment details, cached tool schema, and existing runtime logs were inspected and reviewed with GPT 6.1 Sol in T3 Code. This comment was prepared with its assistance.

Adding another Windows confirmation at the maintainer's request for exact steps and version.

Environment:

T3 Code Desktop Nightly 0.1.10-nightly.20261114.4669
Windows, OS version 10.0.26300.0
Managed Antigravity ACP 1.5.9 (confirmed in both failing runs' initialize responses and language-server version lines)
Selected model: gemini-4-argon

Observed steps:

Start an Antigravity/Argon thread in T3 Code Desktop.
Request a code review.
The turn fails before the review starts.
Submit the same request again; the next turn fails with the identical error.

Existing runtime logs show failures on 2026-11-14 at 15:17:55 and 15:18:44 (local time, UTC+08:00):

INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[63].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

The local cached antigravity-acp/mcp/t3-code/t3_theme_set.json contains:

"version": {"enum": [1], "type": "number"}

No installed app files or cached schemas were modified. Switching this thread to Codex allowed tool calls to run. Other Gemini models and the proposed fix have not been tested on this installation.

This confirms that the matching schema and runtime failure persist in the shipped nightly with ACP 1.5.9. Could this issue be reconsidered?

Posted by an AI assistant at the affected user's explicit request; versions, schema, and error timestamps were checked against the local installation and existing logs.

Same issue on macOS

Using t3code Version 0.1.9 (24e7747) and its managed antigravity 1.4.5 works fine

Still happening on Windows after the close. Independent repro, not a duplicate of the other comments.

Version

T3 Code (Nightly) 0.1.10-nightly.20261114.4669 (db2cc2026427)
Windows x64 (4CE434BNRT-FLA)
Linked fleet on the same nightly: B0Z47C3-BNO (Windows) and n37-018-074 (Linux DevBox)

Steps

New thread on Antigravity, model gemini-4-hydrogen.
Send any message (including a one-line connectivity probe that asks the model not to use tools).
The turn fails in ~1–5s with Provider error: Antigravity stopped this turn because of an error. executedModel stays null.

Same 400 on a fresh delegate_task to gemini-4-hydrogen and gemini-3.8-flash. Antigravity Claude Sonnet 5.5 gets past schema validation (fails later on quota), so this is Gemini-only.

Log (antigravity-acp/log/acp-server-20261114_163616-45284.log)

E1114 16:36:20.324203 errorreport.go:307] agent executor error: generating and executing: INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[63].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

Cached schema antigravity-acp/mcp/t3-code/t3_theme_set.json:

"version": {"enum": [1], "type": "number"}

Downgrade is blocked. Settings → About → Update track to Stable v0.1.9 skips all three machines:

its database has changes 0.1.9 does not support yet; stay on Nightly until Stable has them

Stable itself does not advertise t3_theme_set (landed in #35247 on this nightly), so waiting on #36488 is the only path for this fleet.

tools[63] vs tools[66] in other comments is tool-count, not a different bug.

@juliusmarminge

@juliusmarminge can you reopen this? About 6 people have now confirmed it on macOS and Windows, and the fix is in #36488.

Also, I think your triage bot has a logic bug. Its comment says it "could not reproduce", but that only means it couldn't run Antigravity on its VM. In the same comment it reproduced the root cause with a failing test on main (c63fe9b828). Then it closed the issue as not planned anyway. It seems to treat "couldn't run the steps" the same as "ran the steps and the bug didn't happen".

Title: Gemini/Antigravity provider fails on every turn: t3_theme_set schema has a numeric enum (INVALID_ARGUMENT 400)

Description

Every turn on the Antigravity/Gemini provider fails right away, in every thread and project. The failure happens before the model produces any output:

⚠ INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[67].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

Antigravity stopped this turn because of an error.

(An earlier run had the same error at tools[66]. The index moved when another tool was added.)

Cause (probable)

The path properties[theme].properties[version] matches the built-in T3 MCP tool t3_theme_set. Its schema has a numeric enum:

"theme": {
"type": "object",
"properties": {
"version": { "type": "number", "enum": [1] },
...
}
}

Gemini's FunctionDeclaration schema allows enum only on STRING types. The schema conversion for Gemini seems to turn the numeric 1 into an empty string, and the API then rejects the whole request. Because the T3 tools are sent with every request, no Gemini turn can run while this tool is attached.

Claude and Codex accept the same schema, so the problem only appears with Gemini.

Steps to reproduce

Start any thread with the Antigravity/Gemini provider. The T3 MCP tools are attached by default.
Send any message.
The turn fails with the error above.

Closing and restarting Antigravity does not help, and other projects and threads fail the same way.

Possible fixes

Change the schema to "version": { "type": "integer", "const": 1 }, or remove the enum, or make it { "type": "string", "enum": ["1"] }.
In the Gemini schema converter, drop enum or turn its values into strings when the type is not string, and never send empty enum values.
Check the other T3 tool schemas for numeric or boolean enums.

Environment

OS: Windows 11 Pro (10.0.26300)
Provider: Antigravity (Gemini)
T3 Code version: 0.1.10-nightly.20261114.4682

Another confirmation on macOS, on the newest nightly, 4682. It still happens after 4669.

Version

T3 Code (Nightly) 0.1.10-nightly.20261114.4682 (tag commit 820f620e), local server on the same machine
macOS 27.2.0, arm64 (MacBook Air)
Managed Antigravity ACP 1.5.9, authenticated, compatibility status supported

Steps

Start a new thread on the Antigravity provider.
Send any message.
The first turn ends at once. The only assistant output is:

⚠ INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[63].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

Evidence

The same error is in orchestration_events (message.updated, role assistant) on 3 separate threads on 2026-11-14, at 10:35:13Z, 11:01:36Z and 12:36:45Z. Each is turn 1.
The ACP lifecycle looks healthy before each failure: initialize, authenticate, session/new and session/prompt all show succeeded in the provider event log. The 400 arrives about 1.7 seconds after the prompt starts.
On tag v0.1.10-nightly.20261114.4682, packages/contracts/src/server.ts:628 still has version: Schema.optional(Schema.Literal(1)) in environmentThemeFields. t3_theme_set (apps/server/src/mcp/toolkits/theme/tools.ts) uses that as its theme parameter, which matches properties[theme].properties[version].enum[0].

So 4682 still fails, and I believe the fix in #36488 is still needed. Could this be reopened until it merges?

Investigated with t3 triage, by Claude Opus 5.5 (claude-opus-5-5) in Claude Code.

The likely regression-introducing commit is 42057b82d097156f56f9b487887226b99f018bcb — feat: agents can restyle T3 Code with theme colors and CSS, merged through PR #35247.

That commit introduced t3_theme_set, used the existing EnvironmentThemeFile schema for its theme input, and registered ThemeToolkit with the MCP server:

The theme schema already contained:

version: Schema.optional(Schema.Literal(1))

The numeric literal predates this commit, but PR #35247 exposed it as an MCP tool input. The parent commit has no t3_theme_set tool.

A local schema-generation check using the actual EnvironmentThemeFile, the same theme parameter definition, and advertisedJsonSchema() produced:

"version": {
  "type": "number",
  "enum": [1]
}

This matches the cached tool schema and the properties[theme].properties[version].enum[0] error reported here.

Verification was limited to Git history, source inspection, and a local schema-generation check. Antigravity was not run against the parent and candidate commits, so this is not a runtime bisect result.

Analyzed with GPT 6.1 Sol in T3 Code.

This issue is currently preventing me from using Antigravity with Gemini models in T3 Code. I hope it can be resolved soon, and I appreciate the maintainers’ work on a fix.

Still failing on 0.1.10-nightly.20261114.4682 (macOS 27, arm64, local server, desktop app). Both turns in a fresh Antigravity thread failed with:

INVALID_ARGUMENT (code 400): GenerateContentRequest.tools[66].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

The live MCP server on this build advertises this for t3_theme_set:

"version": {"enum": [1], "type": "number"}

This contradicts the "could not reproduce" closes on #36720 and #36739. The advertisedJsonSchema test passes, but the schema the running server sends still has a number enum. main still has version: Schema.Literal(1) in packages/contracts/src/server.ts, and #36488 is unmerged. Could this be reopened, or #36488 reviewed?

Posted by Claude Opus 5.5 (Claude Code) via T3 Code triage.

this commit works for me hicder@e7409b4

Still affected on nightly 20261114.4682 — every Antigravity Gemini turn fails with ...enum[0]: cannot be empty, including after restart. Root cause verified on main: version: Schema.optional(Schema.Literal(1)) in packages/contracts/src/server.ts advertises a numeric enum Gemini rejects. A community-verified fix is open as PR #36488 but unmerged. Requesting this issue be reopened and the PR merged — Gemini models through Antigravity are currently unusable.

Please reopen. The close comment confirms the root cause: the new test in
apps/server/src/mcp/advertisedJsonSchema.test.ts fails on main with
expected [ 1 ] to deeply equal [] (branch factory/repro-36508, c63fe9b).
The bug is in the advertised MCP schema, so a VM without Antigravity cannot
show it, but the test does.

Since the close, 7 users confirm it on 0.1.10-nightly.20261114.4669
(Windows and macOS, Antigravity ACP 1.5.8 and 1.5.9). Stable 0.1.9 with
Antigravity 1.4.5 works, so this is a regression in the nightly.

Fix: make advertisedJsonSchema emit only string enum values (or drop
enum for theme.version in t3_theme_set).

Still affected, please reopen.

T3 Code server 0.1.10-nightly.20261114.4695, desktop app in WSL mode (Ubuntu backend)
Antigravity provider, model gemini-4-hydrogen, agy 1.5.8, delegated sub-agent thread (full-access)
The turn fails immediately with:
INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[63].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty
Same turn path via the Claude provider (claudeAgent) in the same parent thread works, so it is specific to the Gemini tool-schema validation.

This matches the root cause already described here (t3_theme_set advertising version as a numeric enum from Schema.Literal(1)). The linked fix, #36488, is still open and unmerged. I have not tested nightly 4709.

Still reproduces on 0.1.10-nightly.20261114.4709 (dfd2187), the latest nightly.

Linux x86_64 (Fedora 44), AppImage desktop app
Antigravity provider (ACP)
Every turn fails right away, before any output:

INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[63].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

Antigravity's own log (antigravity-acp/log/acp-server-*.log) has the same error from errorreport.go:307 (agent executor error: generating and executing: ...).

I checked the 71 t3-code MCP tool schemas that Antigravity caches (antigravity-acp/mcp/t3-code/*.json). t3_theme_set is the only one with a non-string enum:

"version": { "enum": [1], "type": "number" }

Gemini's Schema.enum only accepts strings. The 1 arrives as "", and Gemini rejects the whole request, so this one field makes the Antigravity provider unusable.

Possible fix: advertise version as {"type": "integer"} (or leave it out of the advertised schema) and check the 1 on the server. More generally, advertisedJsonSchema could drop non-string enum/const values for every tool.

Could this be reopened?

Confirmed on T3 Code Desktop Nightly 0.1.10-nightly.20261114.4709 (dfd2187) on Windows 11, using the official Antigravity CLI 1.5.3 via an explicit Binary path, with Google account sign-in.

Open a new Antigravity thread with Gemini 4 Hydrogen (Medium).
Send a short prompt such as test.
The thread immediately shows Antigravity stopped this turn because of an error. ACP initialization, authentication, and session creation all succeeded before the failure.

The Antigravity ACP log reports:

INVALID_ARGUMENT (code 400): * GenerateContentRequest.tools[62].function_declarations[0].parameters.properties[theme].properties[version].enum[0]: cannot be empty

Control test on the same machine: agy --model gemini-4-hydrogen --effort medium -p "Reply only with OK." returned OK in PowerShell. This confirms the same failure mode on .4709 with a separately installed CLI and a Google account.

Version 0.1.10-nightly.20261115.4723 (11c425b) with built-in Antigravity 1.5.9 works again

Navigation Menu

Repository navigation

[Bug]: Every Antigravity (Gemini) turn fails with 400 INVALID_ARGUMENT because t3_theme_set declares a numeric enum (`theme.version: {enum:[1], type:"number"}`) #36508

What happened

Cause

Steps to reproduce

Expected behavior

Possible fix

Version

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Every Antigravity (Gemini) turn fails with 400 INVALID_ARGUMENT because t3_theme_set declares a numeric enum (theme.version: {enum:[1], type:"number"}) #36508

Description

What happened

Cause

Steps to reproduce

Expected behavior

Possible fix

Version

Environment

Activity

davisonio commented on Nov 14, 2026

juliusmarminge commented on Nov 14, 2026

davisonio commented on Nov 14, 2026

miles2542 commented on Nov 14, 2026

jakero commented on Nov 14, 2026

MotoGeekops commented on Nov 14, 2026

CEikermann commented on Nov 14, 2026

chrisjian commented on Nov 14, 2026

davisonio commented on Nov 14, 2026

dutzi88 commented on Nov 14, 2026

kashyapmanu commented on Nov 14, 2026

jakero commented on Nov 14, 2026

daviesayo commented on Nov 14, 2026

hicder commented on Nov 14, 2026

AamiRobin commented on Nov 14, 2026

wndrk commented on Nov 14, 2026

luciancsilva commented on Nov 15, 2026

CorsairRom commented on Nov 15, 2026

vgibarraf commented on Nov 15, 2026

CEikermann commented on Nov 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Bug]: Every Antigravity (Gemini) turn fails with 400 INVALID_ARGUMENT because t3_theme_set declares a numeric enum (`theme.version: {enum:[1], type:"number"}`) #36508