[Bug]: Antigravity ACP background tasks are marked completed when the agent stops to wait, hiding active background tasks and dropping agent wakeups in the UI #28415

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. Open an Antigravity ACP thread in T3 Code (e.g., gemini-4-argon / gemini-4-argon-high).
2. Ask the agent to run a command that exceeds WaitMsBeforeAsync (e.g., WaitMsBeforeAsync: 5000 on a command that takes ~30–45 seconds, such as a deployment or test suite) so Antigravity moves the command to a background task (Tool is running as a background task with task id: <conversation-id>/task-<N>) and the agent ends its turn to wait for the background task to complete.
3. Observe the T3 Code thread UI while the background task is still running, and after the background task completes and wakes the agent in the harness.

Expected behavior

1. While the background task is running and the agent is waiting for it:
   • The open background command (run_command / shell / schedule / run_workflow) should remain in a running/pending background state rather than being forcibly marked completed (Ran command) when the initial turn settles.
   • thread.pendingBackgroundTasks should include the running background task so the UI displays the background task indicator/banner (and keeps the thread in a waiting/working state rather than looking completely finished).
2. When the background task finishes and wakes the agent:
   • T3 Code should start a continuation run (or stream the wakeup turn items and assistant messages live into the thread) so the user sees the agent wake up, execute follow-up tool calls, and output its final response without needing to manually send a follow-up prompt.

Actual behavior

1. Thread immediately shows as Done and hides the running background task:
   • As soon as the agent outputs its "waiting for task-<N> to complete" message and ends its turn, finalizeTurn marks the run completed and terminalizeOpenForegroundTools forcibly overwrites the still-running command_execution turn item from in_progress (running) to completed (Ran command).
   • Because all turn items are now completed and providerThread.pendingBackgroundTasks is [], derivePendingBackgroundWork returns []. The UI shows no running background tasks at all, making it impossible to tell whether the agent finished, died, or is waiting on a background task.
2. Agent wakes up in the background when the task finishes, but the UI never shows the wakeup or response:
   • When the background task finishes (e.g., 26 seconds later), the Antigravity harness delivers the <SYSTEM_MESSAGE> task completion wakeup to the model. The agent wakes up in the background, runs follow-up tools, and generates its final completion response (verified in .system_generated/logs/transcript.jsonl), but nothing appears in the T3 Code UI until the user manually sends another prompt.

Root Cause Analysis (on main @ 5e9d56416f6b395095c772c597e79cd5f94e3052)

There are three interacting causes across AntigravityAdapterV2.ts, packages/provider-acp/src/server/adapter.ts, and antigravity-acp:

1. makeAntigravityAcpAdapterFlavor omits enablePostSettleContinuation: true despite AntigravityDriver wiring continuationRequests

• In apps/server/src/provider/Drivers/AntigravityDriver.ts#L413-L428 and apps/server/src/orchestration-v2/Adapters/AntigravityAdapterV2.ts#L228-L236, continuationRequests (ProviderContinuationRequests) is explicitly passed into makeAntigravityAdapterV2 and forwarded to makeAcpAdapterV2.
• However, in packages/provider-acp/src/server/adapter.ts#L1356-L1357:

  const postSettleContinuationEnabled =
    flavor.enablePostSettleContinuation === true && continuationRequests !== undefined;

• Because makeAntigravityAcpAdapterFlavor (apps/server/src/orchestration-v2/Adapters/AntigravityAdapterV2.ts#L154-L216) never sets enablePostSettleContinuation: true, postSettleContinuationEnabled is always false for Antigravity!
• Consequently, when any post-settle session notification arrives while context === null, bufferPostSettleWake (packages/provider-acp/src/server/adapter.ts#L4270-L4277) immediately returns { buffered: false, offerContinuation: false, stopProcessing: false }, offerContinuationRun is never called, and post-settle agent_message_chunk / agent_thought_chunk updates fall through to appendLoadedHistory (adapter.ts#L4722-L4755) where they are silently written into the internal snapshot map without emitting message.updated or turn_item.updated events to the UI.

2. makeAntigravityAcpAdapterFlavor omits extractBackgroundTaskId, causing terminalizeOpenForegroundTools to mark still-running background commands as completed at turn end

• When an Antigravity run_command tool call goes to the background, antigravity-acp (server.py:5490-5495 and 6090-6093) intentionally keeps the tool_call in in_progress state (moving it to session_info.persisted_open_tool_calls without emitting a terminal tool_call_update until the background process actually exits).
• However, when the turn settles in T3 Code, finalizeTurn calls terminalizeOpenForegroundTools (packages/provider-acp/src/server/adapter.ts#L6938-L6947), which checks acpCompletedTurnShouldTerminalizeTool (adapter.ts#L1223-L1231):

  export function acpCompletedTurnShouldTerminalizeTool(
    tool: AcpToolCallState,
    flavor: Pick<AcpAdapterV2Flavor, "extractBackgroundTaskId" | "extractSubagentUpdate">,
  ): boolean {
    const status = toolStatus(tool.status);
    if (status !== "pending" && status !== "running") return false;
    if (flavor.extractBackgroundTaskId?.(tool) !== undefined) return false;
    return flavor.extractSubagentUpdate?.(tool) === undefined;
  }

• Because makeAntigravityAcpAdapterFlavor does not provide extractBackgroundTaskId (e.g., for open execute tools that remain inProgress at turn end, see isAntigravityOpenCommand in apps/server/src/provider/acp/AntigravityProtocol.ts#L317-L319), acpCompletedTurnShouldTerminalizeTool returns true and terminalizeOpenForegroundTools forcibly emits status: "completed" (Ran command) for the still-running background command!
• Because the command_execution turn item is now marked completed, pendingBackgroundTurnItems and derivePendingBackgroundWork (packages/shared/src/orchestrationV2PendingBackgroundWork.ts#L174-L243) return [], so the UI hides the running background command and marks the thread completely idle/done.

3. antigravity-acp (server.py / event_processor.py) stops draining agent.conversation.receive_steps() once session/prompt returns

• In antigravity-acp (google3/cloud/developer_experience/antigravity_extensions/acp_server/server.py:5483), steps from localharness_external are only forwarded to self._stream_live_step(...) inside the async for step in agent.conversation.receive_steps(): loop during an active session/prompt RPC.
• Meanwhile, in localharness_external, when a run_command exceeds WaitMsBeforeAsync, the RUN_COMMAND step remains in STATE_RUNNING (status = 2) while the planner receives the background task ID (<conv>/task-<N>) and finishes its turn, causing localharness_external to emit TrajectoryStateUpdate(state=STATE_WAITING_FOR_TASKS) (4).
• If session/prompt exits on STATE_WAITING_FOR_TASKS, nothing drains agent.conversation.receive_steps() when the background task later finishes and wakes the planner in localharness_external—so the wakeup turn (e.g., steps 253–256 below) runs inside localharness_external without emitting ACP session/update notifications until the next session/prompt call. Conversely, if session/prompt stays open across STATE_WAITING_FOR_TASKS (or spawns a background step drainer that triggers post-settle continuation), T3 Code needs both extractBackgroundTaskId / open background command tracking and enablePostSettleContinuation: true so the UI shows the pending background task while waiting and streams the wakeup turn when it fires.

Impact

Major degradation or frequent failure

Version or commit

0.1.7-nightly.20261031.3991 (and main @ 5e9d56416f6b395095c772c597e79cd5f94e3052)

Environment

Linux x86_64 (CachyOS), T3 Code 0.1.7-nightly.20261031.3991, Provider: Antigravity ACP (gemini-4-argon / gemini-4-argon-high)

Logs or stack traces

Concrete timeline from thread 6af2808e-6d27-43fa-91d1-eda0daffacc3 (Antigravity session c7b20c6f-f402-4c58-ad7b-6f56e7fa6f9c, run ordinal 19):

1. In .t3/userdata/statev2.sqlite (orchestration_v2_projection_runs and orchestration_v2_projection_turn_items):

   • At 2026-10-31T23:15:23Z, the agent launches background command task-251 (tool item ...tool:c7b20c6f-f402-4c58-ad7b-6f56e7fa6f9c:236).
   • At 2026-10-31T23:15:33Z, the agent outputs: "I have launched task-251 in the background to confirm dpl_2a6G1s8uQYFF7a4QnqnxaRrvvKJE reaches READY (PROMOTED) and will report back as soon as it finishes."
   • At 2026-10-31T23:15:48.720Z, terminalizeOpenForegroundTools marks tool:...:236 as status = 'completed' (title = 'Ran command') even though task-251 is still running, and at 23:15:48.749Z run ordinal: 19 is marked status = 'completed' with pendingBackgroundTasks = [].

2. In antigravity-acp/brain/c7b20c6f-f402-4c58-ad7b-6f56e7fa6f9c/.system_generated/logs/transcript.jsonl (steps 251–256):

   • 23:15:23Z (step 251, RUN_COMMAND, status: "RUNNING"): Tool is running as a background task with task id: c7b20c6f-f402-4c58-ad7b-6f56e7fa6f9c/task-251
   • 23:15:33Z (step 252, PLANNER_RESPONSE, status: "DONE"): Agent stops and waits for task-251.
   • 23:16:14Z (step 253, SYSTEM_MESSAGE, status: "DONE"): Task id "c7b20c6f-f402-4c58-ad7b-6f56e7fa6f9c/task-251" finished with result: The command exited with code 0...
   • 23:16:14Z (step 254, PLANNER_RESPONSE, status: "DONE"): Agent wakes up automatically in the background and calls run_command (curl -sS https://text2voice-pi.vercel.app/api/health).
   • 23:16:25Z (step 255, RUN_COMMAND, status: "DONE"): Health check returns {"status":"ok","ok":true,"database":"ok"}.
   • 23:16:28Z (step 256, PLANNER_RESPONSE, status: "DONE"): Agent writes its complete 1,048-token final summary (Everything is now 100% resolved, migrated, merged, and promoted to live production...).
   • In T3 Code (statev2.sqlite): Zero messages or turn items were recorded after 23:15:48.749Z! Steps 253–256 never appeared in the UI.

Workaround

Manually sending a follow-up prompt (e.g., "where are we at?") forces a new session/prompt turn so the agent can report what happened in the background.