Repository navigation
[Bug]: Steer on an Antigravity thread kills the turn (interruptTurn fails, then AcpProcessExitedError) #19689
Description
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
- Open a thread on the Antigravity provider (managed Antigravity ACP runtime installed from Settings > Providers > Antigravity).
- Send a prompt that starts a long agent turn (tool calls, a few minutes of work).
- While the turn is running, type a follow-up message and click Steer.
Expected behavior
The follow-up is delivered into the running turn (or the turn is interrupted cleanly and the follow-up starts a new one). The agent process stays alive.
Actual behavior
The interrupt fails, and about 15 seconds later the whole turn dies. The thread shows the turn as failed, and the Antigravity ACP agent process is gone. The next prompt starts a new agent process (initialize / authenticate / session/resume again).
This happened 3 times out of 3 Steers on one thread, including once after updating Nightly. One interrupt earlier that evening (not from Steer) succeeded, and no drop followed.
Timeline, all 2026-10-14, times in US Central (UTC-5), taken from logs/server.trace.ndjson and logs/provider/events.<thread>.log:
AcpAdapterV2.interruptTurn |
session/prompt ends |
|---|---|
| 6:45:50 PM, Success | no drop |
| 7:09:25 PM, Failure | 7:09:40 PM, failed (AcpProcessExitedError) |
| 7:12:51 PM, Failure | 7:13:07 PM, failed (AcpProcessExitedError) |
| 7:24:50 PM, Failure (after updating to nightly.20261014.3132) | 7:25:05 PM, failed (AcpProcessExitedError) |
Impact
Major degradation or frequent failure
Version or commit
0.0.46 Nightly: nightly.20261014.3118 (first two drops) and nightly.20261014.3132 (third drop). Managed Antigravity ACP runtime 1.3.0.
Environment
Windows 11 Pro 10.0.26200, x64, desktop app
Logs or stack traces
# server.trace.ndjson, AcpAdapterV2.interruptTurn, exit Failure (7:24:50 PM CT)
ProviderAdapterInterruptError: Failed to interrupt antigravity provider turn provider-turn:provider:antigravity:native-turn:provider-instance%3Aantigravity%3A<session>%3Aturn%3A9.
at .../resources/server.asar/apps/server/dist/binCli-CoSutiQf.mjs:172618:63
# server.trace.ndjson, session/prompt, exit Failure (started 7:19:19 PM CT)
~effect/rpc/RpcClientError: RpcClientDefect: ACP protocol terminated.
at emitClientProtocolError (.../resources/server.asar/apps/server/dist/binCli-CoSutiQf.mjs:163895:10)
at .../resources/server.asar/apps/server/dist/binCli-CoSutiQf.mjs:163907:11
# provider events log, session/prompt request
"method":"session/prompt","status":"failed","errorTag":"AcpProcessExitedError"Possibly related, from the Antigravity agent's own logs during the same session (4 times each): cannot kill task "<session>/task-67": task is not running (status: DONE) and T3 Code MCP bridge request failed: fetch failed.
Workaround
Don't use Steer on Antigravity threads. Wait for the turn to finish, then send the follow-up.
Activity
AnobleSCM commentedon Oct 26, 2026
A synthetic ACP child that exits with code 23 reproduces the missing diagnostic without a Steer operation. The current runtime retains its exit code and sanitized stderr, but the run failure displays only
Provider turn failed.and a null code.Proposed reporting fix: #25693. The real-child Antigravity adapter regression checks the failed terminal event; additional cases cover signals, bounded stderr, redaction and native request logging. All process output and identifiers in the tests are made up.
This addresses the missing failure information. The cause of the process exit during Steer still needs its own diagnosis.
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
Real Antigravity is unavailable on the VM, so the reporter's exact UI steps could not be run. On origin/main 0b6f482 I traced Steer for Antigravity: the ACP capabilities declare supportsActiveSteering=false and supportsSteeringByInterruptRestart=true, so Steer calls AcpAdapterV2.interruptTurn (soft, no runtime restart), which calls runtime.cancel. Antigravity's runtime uses cancelBehavior "wait-for-prompt" (apps/server/src/provider/acp/AntigravityAcpSupport.ts:135). That sends session/cancel, waits defaultCancelTimeout = 15 s for session/prompt to settle, and otherwise calls retireRuntime, which kills the child, and fails with AcpTransportError "The ACP agent did not finish cancellation. Its process was stopped." (packages/provider-acp/src/server/AcpSessionRuntime.ts:2367-2406). The adapter wraps that as ProviderAdapterInterruptError, and the in-flight session/prompt then fails with AcpProcessExitedError, matching the reporter's 15 s gap in all three logs. I added an AcpAdapterV2.test.ts case that uses the real mock ACP agent child (acp-mock-agent.ts with T3_ACP_COMPLETE_FIRST_PROMPT_ON_CANCEL) and cancelBehavior wait-for-prompt: start a turn with a long-running tool, interrupt, wait for the agent to receive session/cancel, advance TestClock 16 s, then release the agent's cancel. On main it fails with AcpTransportError at AcpSessionRuntime.ts:2399 because the agent process was already killed. The existing fast-cancel case still passes.
Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.