[Bug]: Antigravity tool items stay open and close with another call's error #31669

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

Steps to reproduce

1. Run an Antigravity (Gemini) thread that reads files and, in the same turn, calls a tool that fails. Two calls that fail reliably are t3-code.link_pull_request without arguments and preview_act with invalid parameters.
2. Watch the thread's tool items, or query them in orchestration_v2_projection_turn_items.

Expected behavior

Each Read item completes when its own file content arrives and shows its own result.

Actual behavior

Read items stay open for minutes and then end as failed, carrying the error of a different call. Across 5 Antigravity threads (2026-10-29 to 2026-11-02), 336 Read items ended with errors that a file read cannot produce:

The second message is the error text of link_pull_request. All 115 of these items sit in turns where link_pull_request was called.

More broadly, 954 of 1,955 Antigravity Read items in the projection ended as failed. Many carry errors from other operations: Agent execution terminated due to error (119), invalid preview_act parameters (116), URL fetch failures (66), browser tab ownership errors (55).

I checked for reused native item ids: no thread contains the same native id twice. The pattern points to items that never get their own completion and are closed later by a failure from another call or from the run.

Impact

Major degradation or frequent failure. Users and agents read the wrong error and chase a problem the read never had.

Version or commit

T3 Code (Beta) desktop 0.1.7; source checked at 2359643 (2026-10-31)

Environment

macOS 27.2 on Apple Silicon, Antigravity provider with gemini-3.8-flash, gemini-3.8-flash-high and gemini-4-argon

Logs or stack traces

status=failed toolName=Read input={"AbsolutePath": "<file>", "StartLine": 40, "EndLine": 65}
output="Error in MCP tool execution: Pass either url, or both repository and number."

Possible fix

Match each Antigravity tool result to its item by the native call id, close the item on that result, and keep turn-level or run-level failures off items that already have their own result. The driver lives in apps/server/src/provider/Drivers/AntigravityDriver.ts.

Workaround

Judge an Antigravity run by its git diff, not by the error shown on its tool items.