Antigravity: a command still running after the reply is marked completed, and Stop cannot end it #16442

Activity

1. juliusmarminge commented on Oct 6, 2026

   

   juliusmarminge

   on Oct 6, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @yaacovcorcos for the clear report and the mock-agent repro, that made this quick to trace.

   What I found

   • This looks like a regression of fix(antigravity): let Stop end commands that outlived their turn #13388 that was lost when the V1 Antigravity adapter was replaced by the V2 ACP adapter.
   • isAntigravityOpenCommand still classifies an execute tool that is inProgress after end_turn, and its tests still describe only those commands as background work, but makeAntigravityAcpAdapterFlavor never uses it.
   • On end_turn, finalizeTurn marks every still-running foreground tool completed and emits turn.terminal with status completed. Antigravity doesn't set deferFinalizeForBackgroundWork, terminateRuntimeProcessGroupOnInterrupt, or a detached process group.
   • After that, interruptTurn with requestRuntimeRestart: true finds no active turn and returns. Stop during the turn only sends session/cancel (cancelBehavior: "wait-for-prompt"), which doesn't end commands the agent already started.

   Likely fix area

   The direction in your report lines up with how Grok is already wired, and would be one option:

   • Treat an execute tool still inProgress after end_turn as background work that holds the turn until it finishes or the user presses Stop. Pending (not yet approved) tools wouldn't hold the turn.
   • On Stop, end the turn as interrupted and tear down the agent process group, respawning for the next turn, as Grok does. As you noted, a child that starts its own session would still be out of reach on macOS.
   • Keep subagent batches going idle when the root prompt ends, since Antigravity never reports them finished. subagentsIdleOnTurnCompletion already idles them at finalize, so they shouldn't pin deferred finalize.

   A mock-agent test covering those three cases would fit whichever approach is chosen. A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 6, 2026
3. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   Reproduced on Linux with Node 24 and main a12d6ed942, using the real web dev app and an Antigravity-profile ACP mock that launches sleep 120.

   Returning end_turn after an in-progress execute update marks the run and command completed while the captured child processes remain alive; Stop is no longer offered. This also reproduces without an exit_code field. In a separate active-turn attempt, clicking Stop marks the run interrupted but leaves the command alive.

   End-turn recording, runtime transcript, active-Stop recording, active-Stop transcript.

   Live Antigravity and macOS were not tested.
4. juliusmarminge

   added

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   and removed

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Oct 22, 2026
5. Xuanwo commented on Nov 12, 2026

   

   Xuanwo

   on Nov 12, 2026

   More actions

   I encountered the same visible failure with a real authenticated Antigravity session on November 12: T3 showed “Worked for 5m 53s” after the assistant said a background scan was still running and promised to report its results. No automatic follow-up appeared before I manually asked for the results about 23 minutes later.

   Environment:

   • Linux x86_64; T3 server version 0.1.9 (from the running server's runtime metadata).
   • T3-managed Antigravity ACP 1.4.5 (from _version.py in the installed agy_acp_server.par), model gemini-4-carbon, full-access mode.

   The task was to inspect local JSONL traces for their suitability as encoding test data and identify redaction requirements. The assistant launched a Python scan of approximately 945 MB and identified it as background task task-104.

   Observed timeline, all UTC on 2026-11-12:

   • 06:55:31.736: provider log records session/prompt starting.
   • 07:01:24: the assistant's last reply says, translated: “The background scan is inspecting the field structure and sensitive-information matches in approximately 945 MB of raw JSONL. I will summarize the conclusions when it finishes.”
   • 07:01:24.323: provider log records session/prompt as succeeded.
   • 07:01:24.344: T3 records the run as completed. The scan's command item is also marked completed, but its recorded text contains the launch script without an exit code or scan results.
   • 07:24:25.556: my manual “Are the results available?” message starts the next run. There is no intervening automatic run or visible follow-up in T3's timeline.

   This is evidence from an actual user session, not an ACP mock. I have not inspected the native Antigravity trajectory to establish whether it continued internally during that gap. The provider log also summarizes the prompt response without exposing its stopReason, so I cannot claim to have captured end_turn on the wire. I did not test Stop or process cancellation.

   The user-facing problem is that T3 presents the work as finished while the last reply explicitly says it is waiting for background work, and no result arrives without another user message. This appears consistent with the missing-background-work/wakeup symptoms discussed in #28415; the native execution and notification-delivery boundary remains unverified in this case.
6. travelvector commented on Nov 13, 2026

   

   travelvector

   on Nov 13, 2026

   Contributor

   More actions

   Additional evidence from a real Windows x64 session using T3 Code Server 0.1.10-nightly.20261112.4580, Antigravity CLI agy 1.5.6, and gemini-4-hydrogen (High). T3 was configured to launch the local CLI with acp --process-per-session.

   This looks consistent with the background-command and wakeup symptoms described here and in #28415. The following observations are from existing session records; this is not a new controlled reproduction or a protocol-wire capture.

   Observed in one run

   1. The agent launched a command with WaitMsBeforeAsync: 10000, then said it was still running and promised to report the result.
   2. The T3 provider log recorded session/prompt as succeeded, and the T3 run became completed at approximately the same time, while the command was still running.
   3. A user follow-up started another run about 11 seconds later. The original command exited about 47 seconds after the initial run was marked complete.

   Observed in a separate run in the same session

   1. T3 marked the run completed while a background command was still pending.
   2. Approximately 76 seconds later, the native Antigravity task completed. Its native trajectory shows the agent waking about 6 seconds later, reading the task result, and issuing another tool call before the next user message.
   3. The T3 event store contained no events for that thread between the completed run and the next user message, approximately 190 seconds later. When the next prompt started, the earlier native activity appeared in the T3 timeline under the new run.

   Expected: T3 should accurately represent the outstanding command and surface the agent's continuation and final result without requiring a user follow-up. A long-lived daemon can have a separate lifecycle from a finite command whose result the agent is waiting for.

   Evidence boundary: The local provider log summarizes the session/prompt result without exposing its stopReason, so this report does not assert that end_turn was captured on the wire. I did not test the Stop button or process cancellation. No raw logs, account identifiers, project details, local paths, network addresses, or attachments are included.