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

Abierto
  • ¿Algo no está bien?
#36,105 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
8/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
go, typescript
Área
ai, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
59 min
PR fusionados (30 d)
418

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.