[Bug]: Antigravity ACP marks successful file reads as failed #20095

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

Antigravity successfully reads files and receives their complete contents, but T3 later displays those reads as failed with Tool execution failed. In the observed incident, an unrelated MCP argument-validation error caused the ACP server to flush previously announced file-read calls as failures.

This makes successful skill loading look broken. The same problem affects reads of cached MCP results, not just SKILL.md files.

Steps to reproduce

Observed sequence on a real session; this has not yet been reduced to a separately tested deterministic reproduction:

1. Start an Antigravity conversation using Gemini 4 Argon High with the managed ACP runtime 1.3.0.
2. Have the agent read several workspace SKILL.md files using view_file, then make MCP calls and read their cached result files.
3. Later in the same turn, an MCP list_issues call fails input validation because one element of fields is unsupported (fields.7).
4. Observe that earlier Read rows become failed with the generic message Tool execution failed.
5. Compare those rows against the corresponding records in the native transcript_full.jsonl: the earlier view_file results are DONE and contain the file contents.

Expected behavior

Each Read row should reach its terminal state when that read completes and retain its actual result. A later, unrelated tool failure should affect only the appropriate call. Genuine read failures should remain distinguishable from missing completion notifications or interrupted work.

Actual behavior

In the captured T3 timeline, 21 Read rows were marked failed. The native full transcript contains 25 successful view_file results overall. The three initial skill reads were checked individually against their local files:

The file comparison used the decoded result value from each Tool response for view_file record in transcript_full.jsonl. The shortened transcript.jsonl is insufficient for this comparison because it truncates long records.

These observations establish successful reads and incorrect reported states. They do not establish whether the model followed every instruction in the skills.

Impact

Minor bug or occasional failure

The timeline falsely reports failures for successful file reads, undermining diagnosis of skill loading and tool execution.

Version or commit

T3 Code Nightly 0.0.46-nightly.20261015.3171.

Environment

Linux x86_64; managed Antigravity ACP runtime 1.3.0; gemini-4-argon-high.

Logs or stack traces

Sanitized native warning, with unrelated IDs and local paths omitted:

21:57:07 server.py:5477
Step error encountered; flushing open tool calls:
  read-a: view_file
  read-b: view_file
  read-c: view_file
  ... other earlier view_file calls ...
  current-mcp-call: list_issues
Error: <empty>

The native transcript records the independent failure as:

step 55: MCP_TOOL, ERROR
Input validation error: Invalid arguments for tool list_issues: fields.7:
Invalid option: expected one of <allowed field names>

Diagnosis and fix direction

The installed Google ACP server archive includes readable Python source. In server.py, _stream_live_step, lines 5473–5491 of this runtime:

• An SDK step with status ERROR iterates over all entries in open_tool_calls.
• It emits tool_call_update with status failed for each entry.
• With an empty step error, it uses the fallback Tool execution failed.

The native warning explicitly includes the IDs of the three already successful skill reads. This identifies where the false failures are emitted. Why their successful host-tool completions did not close the ACP calls still needs investigation; simply treating every failed read as successful would hide real errors.

For comparison, _stream_live_step extracted from the checksum-verified 1.4.0 Linux runtime is byte-identical to the 1.3.0 method (SHA256 aa4dc3cfcf243b9da1623b2215a30082a0c41b617e9050af83f57301d01898f7). This is a source comparison, not a live test of 1.4.0. There is no verified fix from upgrading to that version.

This appears to originate in Google's ACP runtime rather than in the workspace skill files. Please investigate or forward upstream the missing completion correlation and the broad error flush. T3 should preserve accurate per-call results rather than compensate by masking all failures.

Screenshots, recordings, or supporting files

The report above contains sanitized comparisons and the relevant warning. Full workspace contents and native transcripts are omitted because they contain unrelated private material.

Workaround

For diagnosis, compare affected rows with the native full transcript and the actual file contents. No verified UI/configuration workaround is established. Rewriting skill files or changing shell configuration is not indicated by this incident.

Related issues

• [Bug]: Gemini always show "Monitoring" after finishing a task and it seems to never end #12325: Antigravity remains in Monitoring after completion; different symptom.
• [Bug]: Antigravity turns crash on transient network drops (502 Bad Gateway / model unreachable) instead of retrying #16010: transient network failures stop Antigravity turns; different trigger and recovery issue.