[Bug]: Antigravity/Gemini randomly hangs in thinking, then session/cancel fails and the thread cannot recover#14619

Triage

Thanks for the report, @heykerim. This is a real bug, and it's still present on main (5cc99e1c23). It isn't a duplicate of #11670 (open issue). In that issue the Antigravity stream dies with a raw EOF. Here the thread sits in thinking with no error until you press Stop, and then Stop fails. You don't need to look up your version, because this code path hasn't changed since your build.

What's happening

An Antigravity turn has no progress timeout. The session stays running as long as session/prompt is open, so if Gemini stops sending updates and never finishes that call, the timer keeps counting until you click Stop.

Stop for Antigravity sends session/cancel and then waits up to 15 seconds for the prompt to finish (cancelBehavior: "wait-for-prompt"):

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/apps/server/src/provider/acp/AntigravityAcpSupport.ts#L67

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/apps/server/src/provider/acp/AcpSessionRuntime.ts#L968-L1004

session/cancel is a notification, not a request, so the error you saw doesn't come from the cancel itself. If the prompt doesn't finish within 15 seconds, T3 kills the agent process and raises a made-up AcpTransportError for session/cancel. Its message leaves out the useful detail ("The ACP agent did not finish cancellation. Its process was stopped."), so all you see is ACP transport operation call-rpc failed for method session/cancel.:

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/packages/effect-acp/src/errors.ts#L173-L177

The other message, "The request was canceled by the client.", is the open session/prompt coming back after the cancel. Instead of treating it as a normal cancellation, interruptTurn passes it on as a session/cancel failure, so the turn is never marked as cancelled:

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/apps/server/src/provider/Layers/AntigravityAdapter.ts#L1136-L1188

Because the process gets killed, the runtime stays in a failed state, and the next prompt runs into the same unrecoverable session as #11670.

What's upstream and what's ours

The agent going silent and not finishing the cancel quickly is upstream, in agy and Gemini. T3 owns the rest: there's no stall timeout while a prompt is open, cancel errors show up as a transport failure, and Stop doesn't mark the turn as cancelled. #11626 (closed PR, not merged) targeted these same error strings. It also raised the cancel wait from 15 seconds to 60, which is a product decision.

Proposed fix

1. When the prompt fails because a cancel was requested ("The request was canceled by the client." or a context-canceled error), complete the turn as cancelled instead of reporting a session/cancel transport error.
2. When the 15-second wait runs out, still stop the process, but mark the turn as cancelled, and if an error is shown at all, show the real detail.
3. Keep the 15-second default unless maintainers agree to change it.

A trace is optional. If you still have the run, the useful part is from the last session/update to the moment you clicked Stop: the thread id, when you clicked Stop, and whether a process exit follows the cancel.

Adding the deterministic repro notes and trace details as requested from #14854:

Deterministic Reproduction: Active Background Task + Queued User Message

While this issue also occurs intermittently during long "thinking" turns, we found a 100% reproducible trigger involving background tasks:

1. Background task started: During a turn, the agent runs a persistent service (e.g. bun run dev / npm run dev), which the Antigravity harness tracks as a running background command task.
2. Text generation finishes: The assistant streams its complete answer text to the UI.
3. Turn remains open on backend: Even though no more text or tool calls are pending, the session/prompt call never completes because the background process is alive and occasionally emitting activity updates (tool.updated). In our logs, AntigravityAdapter.sendTurn remained active for 462,564 ms (~7.7 minutes).
4. User queues a follow-up message: Seeing the response on screen while the composer shows the turn still running, the user submits a new prompt. The message enters the queue.
5. Preempting the turn triggers session/cancel: T3 Code picks up the queued message, dispatches thread.turn-start-requested, and calls interruptTurn -> session/cancel.
6. 15s cancel timeout expires: Because Antigravity uses cancelBehavior: "wait-for-prompt", T3 Code awaits activePrompt.value.fiber with defaultCancelTimeout (15s). With the background task still attached, Antigravity doesn't exit the prompt fiber within 15s.
7. Fatal session crash: At 15,019 ms, timeoutOption raises AcpTransportError, invokes retireRuntime, and stops the session (status: "stopped" / session.exited).

Relevant Log Traces

From server.trace.ndjson:

Timeline from SQLite orchestration_events & provider event stream:

This confirms the proposed fix in triage: handling cancel timeouts / prompt interrupts without retiring the entire adapter runtime will completely prevent this crash.

Same issue here, hope it will be fixed soon ! ❤️

Adding Windows diagnostic evidence from T3 Code Desktop 0.0.45, Antigravity ACP 1.1.1, and gemini-3.8-flash-high, based on SQLite events, provider logs, and server.trace.ndjson.

Thread: d1c68c22

Timeline (October 10, 2026, UTC)

• 13:38:55.824Z: Two background bash tasks started during an earlier turn.
• 13:41:11.933Z: Incident B (background-task hang): Turn a709e65a started and remained running for over an hour without new assistant output.
• 14:50:53.510Z: A follow-up prompt triggered session/cancel.
• 14:51:08.524Z: The 15-second cancellation watchdog expired, triggering AcpSessionRuntime.retireRuntime.
• 14:51:08.644Z: The affected turn entered state: "error".
• 14:51:58.960Z: A subsequent turn completed successfully on a new ACP runtime without restarting T3 Code.
• 16:33:50.432Z: Incident A (mid-stream stall): Turn eb220536 stopped generating text mid-sentence.
• 16:33:50.432Z–17:15:30.853Z: No further provider updates for 41m 40s, despite the T3 server remaining responsive. No active background commands were identified during this stall.
• 17:15:30.853Z: User manually interrupted the turn.
• 17:15:45.869Z: The cancellation watchdog expired, and AcpSessionRuntime.retireRuntime executed.
• 17:15:45.878Z: Provider logs recorded session/prompt failing with errorTag: "Interrupt", followed by session.exited.
• 17:15:45.886Z: The database recorded state: "interrupted" with completed_at: "17:15:30.855Z", approximately 15 seconds before the watchdog expired.
• 17:16:35.009Z–17:16:38.232Z: A new ACP runtime successfully executed session/resume in approximately 3.22 seconds.
• 17:16:54.243Z: The subsequent turn completed successfully without restarting T3 Code.

These findings add two details to the existing triage:

1. Mid-stream generation can stall without an identified active background command, suggesting a scenario distinct from the previously reported background-task hang.
2. Cancellation timeouts surface transport errors and leave affected turns in interrupted or error states, but do not necessarily prevent subsequent prompts from succeeding.

Thanks for the report. This fault is outside T3 Code, so we cannot fix it here. Please report it to the project that owns that tool. If you find a fault in T3 Code itself, please open a new issue with steps to reproduce it.

Following up on the request above for traces, identifiers, the runtime version, and whether it still happens on current code. I hit this in my own install and then reproduced it on current main in an isolated dev instance. Short version: it still happens on main at 6f75bcb374, and it reproduced on the first attempt with a simple trigger, and once a thread has hit it, later turns in the same thread stall too.

Environment

• macOS arm64, Antigravity ACP runtime 1.3.0 (the managed release whose SHA-256 is pinned in antigravityRelease.ts), model gemini-4-argon-high, Google account sign-in.
• Original incident: my installed build, a localized 0.1.1-zh.2 based on v0.1.1. Its patches change web/desktop display strings and layout, plus one server change to the Antigravity quota request User-Agent (antigravityUsageLimits.ts). None of them touch packages/effect-acp, packages/provider-acp, or the Antigravity adapter's turn, cancel, or process lifecycle.
• Reproduction: unmodified main at 6f75bcb374 (2026-10-21), vp run dev in a separate worktree with its own --home-dir, so nightly-equivalent code.

Reproduction on main

All times UTC, 2026-10-22. Thread IDs are from the isolated dev instance.

Test A, thread 4cacdc2e-5221-42e6-b81f-b93f1b040a74. Prompt: "Start a local static file server in this repo with python3 -m http.server 18765 as a long-running background process. Do not wait for it to exit and do not stop it. Once it is listening, reply with exactly: SERVER STARTED"

So the answer was complete about 20 seconds in, but the turn stayed running for 5 minutes until Stop, and Stop took the full 15-second cancel window.

Same thread, next turn. Prompt: "Reply with exactly: RECOVERED". Before sending it, I manually killed the leftover server process (see "Leftover child process" below).

At 05:12:11, mid-stall, agy_acp_server.par used 0% CPU. Its only non-loopback socket was a CLOSE_WAIT connection to daily-cloudcode-pa.googleapis.com:443, and the two localharness_external children had only loopback sockets.

Controls, same instance and project:

• New thread 1f869fe4-2a69-4424-9e97-ad6ded9c5bb7, "Reply with exactly: CONTROL OK": session/prompt started 05:12:56.365, succeeded 05:13:00.788.
• Test B, new thread 695a9974-b72f-4eee-8b3c-787a19a999e9, the server started fully detached with nohup python3 -m http.server 18766 >/dev/null 2>&1 &: session/prompt started 05:13:21.844, succeeded 05:13:34.083.

So the stall needs a command that the agent is still tracking as running (Test A). A detached process (Test B) does not trigger it. Once a thread has stalled this way, the restored session (session/load) stalls the following turns too, even after the process is gone. This matches the background-task trigger @GorlikItsMe described above, and adds the "stays stuck after reload" part.

Original incident (installed 0.1.1-zh.2)

Thread 324c2731-5f27-414e-a487-13c87da327b6. Its first 3 prompts succeeded. The 4th turn was the first to leave two native tool calls that never completed, and from then on 26 consecutive prompts never returned: each one ended only when Stop or a queued follow-up message forced a runtime restart (AcpProcessExitedError). One of those turns sat for about 7 hours before I stopped it. Across 24 Antigravity threads on this machine (101 prompts, 75 succeeded), this is the only thread with never-completed tool calls, and it accounts for all 26 failures.

Latest incident, from server.trace.ndjson and the provider event log:

Leftover child process

In Test A, after retireRuntime killed the ACP process, the python3 -m http.server it had started kept running, reparented to PID 1 in its own process group and still listening on its port. I had to kill it by hand. This seems to be a separate problem (process cleanup on Stop), but it has the same trigger. I'm happy to file it separately if that's preferred.

Notes

• The ACP runtime's stderr is dropped (packages/effect-acp/src/_internal/stdio.ts, stderr: () => Sink.drain), so there is no runtime-side log of what it was waiting on.
• I haven't tested #21439 against this repro.
• The exact prompts above should reproduce this on any machine with an Antigravity account. I have the full provider event logs and trace excerpts locally and can share more on request.

Reopening: our earlier "upstream" close was wrong for part of this. A reporter reproduced it on current main: the thread does not recover after a failed Stop, and the process the agent started keeps running after Stop. #21439 targets the recovery part.