Antigravity CLI 1.5.7 ends turns on background waits and stalls wakeups in forced default mode

Aperta
  • Qualcosa non va?
#36,105 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
go, typescript
Ambito
ai, backend

Direzione di ricerca

The behavior lives in T3's Antigravity adapter, where subagentsIdleOnTurnCompletion: true and the antigravityCliSessionMode mapping decide when a turn finishes and which mode is sent. The server.go log lines and the session/prompt and session/update traffic come from the external CLI, so reproducing them needs the 1.5.7 CLI installed. Done would mean a background wait keeps the turn open or reattaches a prompt, and a woken edit reaches a confirmation the user can answer. Related: #16442, #30082, and PRs #28450, #30083, #35073.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

After managed Antigravity installs migrated to the native CLI 1.5.7 in #35487, any turn that launches a background shell command and pauses to wait for it gets marked completed in T3 Code immediately, and subsequent work on wakeup hangs until the user sends another message.

With the legacy 1.4.5 ACP server agy_acp_server.par, waiting across finite background commands stayed inside the open turn because receive_steps() kept streaming updates and skipped closing unfinished background execution tools until no background shell command remained active. Issue #16442 already covers the infinite daemon case.

On CLI 1.5.7, two behaviors combine to break finite background tasks even when the thread is set to full access.

First, as soon as the model pauses to wait on a background command, 1.5.7 closes its step stream, logging Stream goroutine exited for <id>, sending completion signal in server.go, and resolves session/prompt cleanly. Because T3's Antigravity adapter sets subagentsIdleOnTurnCompletion: true and does not defer turn finalization for background commands or reopen a continuation prompt when work resumes, T3 marks the run finished right away and shows the composer as idle.

Second, when the background command finishes later and wakes the agent internally, 1.5.7 has no attached session/prompt request open. It emits zero session/update notifications back to T3, so allowed read calls run silently with nothing visible in the thread. Then, because antigravityCliSessionMode maps yolo and auto_edit to default since the CLI rejects those modes, the first edit or shell command on wakeup clears 1.5.7's internal safety check sir_flash_lite with triggered=false and blocks indefinitely waiting for an ACP tool confirmation that can only be answered inside an active session/prompt call.

In a trace captured on 0.1.10-nightly.20261113.4630 with CLI 1.5.7 and full access enabled, session/prompt succeeded right as server.go exited the stream goroutine while background tests were still running. About 70 seconds later the agent woke internally, ran an allowed read check silently, cleared sir_flash_lite on an edit_file step, and sat frozen for over 14 minutes with no ACP output until a manual user message started a new session/prompt. Roughly 0.3 seconds after that new session/prompt arrived, server.go logged Tool confirmation ... approved=true on the stalled step and resumed.

Related issues #16442 and #30082 plus open PRs #28450, #30083, and #35073 track passive UI turn holding and missing continuation turns. For CLI 1.5.7 specifically, passively holding the run open without keeping or reattaching a session/prompt request will still drop wakeup updates and leave woken edits and commands stuck on confirmation while sessions are forced into default mode.

Lingua principale
TypeScript
Stelle
24.8k
Fork
6.4k
Merge medio
59m
PR unite (30g)
418

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pingdotgg/t3code

Tutte le issue di pingdotgg/t3code

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.