[Bug]: Antigravity supporting turn fails executor startup on t3-code roots notification with Bad Request

Start in apps/server, where the executor is built and the t3-code MCP startup sends notifications/roots/list_changed over ACP. The report says the T3 roots-change handler and several HTTP admission paths can each return 400, so first find which path handles that notification and what it rejects. Done means identifying the rejection reason, or adding redacted logging that shows the method, protocol version, session-header presence and status, and then a clean executor start for a text turn followed by a supporting turn.

[!NOTE]
Written by GPT-6.1 Sol on behalf of @seankoji

Before submitting

• I searched existing issues and did not find an exact duplicate in the searches performed.
• I included enough detail to investigate the problem.

Area

apps/server

Steps to reproduce

Observed sequence on 13 November 2026, at 18:51 AEDT, UTC+11. This is an existing incident, not a newly run or proven deterministic reproduction.

1. Start a fresh Antigravity session using gemini-4-hydrogen-high, provider options {}, and runtime mode full-access. The assigned task was read-only.
2. Send an initial text-only prompt and wait for it to complete.
3. Send a supporting message in the same session with three small WAV files and two small MP4 files, each below the native attachment size limits.
4. All five uploads return HTTP 204. Stored-file byte checks match the prepared inputs.
5. The supporting turn fails while constructing the executor, with the error below.

The observed input was a mixed WAV/MP4 message. A WAV-only synthetic reduction has not been run. The evidence does not establish that media is necessary to trigger the failure.

Expected behavior

After the initial text turn completes, the supporting turn should construct its executor and complete the T3 MCP startup/roots-notification exchange so the provider can process the message.

Actual behavior

Executor construction fails while sending notifications/roots/list_changed to t3-code, reporting HTTP 400 / Bad Request. The ACP request returns successfully carrying the host error, and T3 records the turn as failed.

A retained provider-local conversation receipt contains the complete original WAV bytes before the executor failure. This rules out alleging that these WAVs never reached provider-local storage. It does not prove backend receipt or native hearing. No audio-format or model-capability rejection was established.

Impact

Major degradation or frequent failure.

The affected supporting-media workflow cannot proceed to a usable result despite a successful first text turn and successful uploads. This report does not establish failure across all T3 sessions or providers.

Version or commit

T3 Code server 0.1.10-nightly.20261113.4616, verified as the actual running server during the existing investigation.

Environment

• Linux x64.
• Antigravity ACP provider, model gemini-4-hydrogen-high. High is encoded in the model ID; provider options were {}.
• Runtime mode full-access, with read-only task scope.
• Managed installation record and archive identify Antigravity 1.3.0. This is installation evidence only. The exact executed binary, per-run handshake version and any binary override are unknown.
• Browser/client and Node/Bun versions were not retained.

Logs or stack traces

Relevant retained ACP timeline, UTC on 13 November 2026, equivalent to 18:51 AEDT:

07:51:12.365  initial session/prompt started
07:51:17.426  initial session/prompt succeeded
07:51:20.255  supporting session/prompt started
07:51:20.296  ACP response returned carrying the host error

failed to construct executor: MCP load failed for t3-code: sending "notifications/roots/list_changed": Bad Request

Screenshots, recordings, or supporting files

None attached. This report contains only redacted observations.

Workaround

None verified. A later resumed text turn added no fresh media to its new stored input. Earlier backend-history retention is unknown, so that resume does not verify recovery of the supporting-media workflow.

Investigation limits and verification criteria

The exact HTTP 400 cause remains unresolved. Existing static inspection found a T3 roots-change handler and multiple HTTP admission paths that can return 400. No retained rejection headers/body identifies which path rejected this exchange. There is no evidence here for a specific missing-header defect or an unsupported-notification defect.

The installed MP4 path is separately gated by reported Antigravity version, platform and resolved model. This report does not establish native video delivery or a separate video-gate bug.

Useful verification would show a clean executor start for an initial text turn followed by a supporting turn on a verified runtime. If the rejection recurs, redacted method, negotiated protocol, session-header presence, HTTP status and rejection reason would make it actionable without private prompts, credentials or media. Native media perception needs separate verification after startup succeeds. No patch or verified fix is reported.

Related public context

• #17066 concerns native MP4 support.
• #24969 and its redirect to #25292 concern binary file-reading behavior. They do not cover this roots-notification executor failure.
• #20097 concerns MCP startup failure being recorded as completed. In this incident T3 correctly recorded failure; the reported bug is the startup exchange itself, not completion classification.