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

Ouverte
  • Quelque chose ne va pas ?
#36,105 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
8/100
Type d'issue
Bug
Clarté
À clarifier
Activité
Active
Stack technique
go, typescript
Domaine
ai, backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
24.8k
Forks
6.4k
Merge moyen
59 min
PR mergées (30 j)
418

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de pingdotgg/t3code

Toutes les issues de pingdotgg/t3code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.