[Bug]: Gemini always show "Monitoring" after finishing a task and it seems to never end #12325

Activity

1. aledeul

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 17, 2026
2. juliusmarminge commented on Sep 17, 2026

   

   juliusmarminge

   on Sep 17, 2026

   Member

   More actions

   Triage

   Verdict: likely confirmed (provider lifecycle / liveness, not a desktop-only UI glitch). Confidence medium-high on the mechanism; medium on “always,” because the report has no logs or screenshot.

   Area (filed): apps/desktop
   Area (actual): apps/server Antigravity adapter + shared web/desktop Monitoring pill (apps/web)
   Already fixed on main? No.
   Duplicate of: none. Same class as Grok leftover monitors, not the same bug.

   Suggested title (optional): [Bug]: Antigravity/Gemini leaves "Monitoring" after the turn ends

   What happened

   Reporter (@aledeul, macOS, T3 0.0.42): after a Gemini task finishes, the thread stays on Monitoring and never leaves that state. Expected: Monitoring should stop. Impact: minor. No logs, screenshot, or step-by-step repro.

   In T3, “Gemini” is the Antigravity provider (Google ACP; models such as gemini-3.1-pro). Desktop hosts the same web chat/sidebar, so the pill is not Electron-specific.

   Diagnosis

   Monitoring is not a generic “busy” label. The sidebar / composer banner show it only when in-memory backgroundLiveness === "monitoring": live watch-loop tasks (monitor, monitor_mcp, local_bash, shell) and no live agents.

     // The turn can settle while native background work runs on. Subagent and
     // workflow fleets read as plain Working; Monitoring is reserved for watch
     // loops (a parent agent babysitting a PR, tailing checks) with no other
     // live work.
     if (thread.backgroundLiveness === "working") { ... }
     if (thread.backgroundLiveness === "monitoring") {
       return { label: "Monitoring", ... };
     }

   For Antigravity, any execute tool still inProgress when the prompt returns end_turn is promoted to a background local_bash task. local_bash is a monitor type, so the pill flips to Monitoring after the turn settles:

   /** Only commands still running after end_turn become background tasks. */
   export function isAntigravityOpenCommand(toolCall: AcpToolCallState): boolean {
     return toolCall.kind === "execute" && toolCall.status === "inProgress";
   }

     const promoteBackgroundCommands = (context: SessionContext) =>
       // ...
             yield* emit({
               type: "task.started",
               payload: { taskId, taskType: "local_bash", toolUseId: id, ... },
             });
     // finishTurn → promoteBackgroundCommands(context) then turn.completed

   Those tasks clear only if:

   1. Antigravity later sends completed / failed for that tool, or
   2. the session is torn down (finishBackgroundCommands / session.exited), or
   3. the server restarts (liveness is in-memory only).

   If Gemini ends the turn while an execute tool is still inProgress and never sends a later terminal tool update, Monitoring stays up. That matches “after finishing a task” and “never ends,” especially if it happens on every turn (stale inProgress execute, or a harness-owned watcher that never completes).

   Two extra reasons it feels stuck:

   • Idle reaper and auto-settle skip these threads (ProviderSessionReaper, ThreadSettlementPolicy), so a leftover monitor also keeps the session alive.
   • Banner Stop is a turn interrupt, not session teardown. Antigravity interruptTurn only runtime.cancels the current prompt. After end_turn there is no prompt, and it does not emit task.completed for promoted commands. fix(web): stop background work through session teardown #11159 (fix(web): stop background work through session teardown) is still open and is aimed at this Stop path. The composer comment that Stop “kills every live background task” is not true for Antigravity today.

   This is not the Grok bug. #9139 / #11680 are Grok task_completed notices. Same user-visible pill, different adapter.

   Why this is likely a bug

   Promotion of real leftover shells (watch / tail) is intentional (AntigravityAdapter.test.ts “tracks native commands that survive a turn”). Showing Monitoring forever after an ordinary finished Gemini turn is not.

   Most likely: Gemini/Antigravity ACP reports end_turn while one or more execute tools are still inProgress, and T3 promotes them with no later completion. Less likely, but possible: the user started an actual watcher and expected it to auto-stop.

   A no-tool “hello” turn should not show Monitoring. If it does, promotion or classification is wrong. If it only happens after a command/tool turn, we still need a completion or timeout so a finished task cannot pin the pill.

   Workaround

   • Restart the T3 server (clears in-memory liveness).
   • Stop the provider session (full teardown), not only banner Stop, until fix(web): stop background work through session teardown #11159 or an adapter fix lands.
   • If a real watcher is running, that pill is expected until the command exits.

   Questions for the reporter

   1. Provider: Antigravity (Google Gemini models) or Gemini through OpenCode?
   2. Does a no-tool “hello” turn also stick on Monitoring, or only turns that ran a command?
   3. Screenshot of the pill and composer banner after the turn ends?
   4. Does banner Stop clear it, or only a full restart / new session?
   5. Provider event log around task.started / task.completed / turn.completed for one stuck thread (redact secrets)?

   Recommended next step

   Keep as an open Antigravity lifecycle bug. Fix in the adapter, not desktop chrome:

   1. Do not leave promoted local_bash tasks live after end_turn unless they are clearly still running (or honor an Antigravity completion notice, same idea as fix(grok): close background tasks when grok reports task completion #11680 for Grok).
   2. Make post-turn Monitoring Stop tear down the session / finish promoted commands (fix(web): stop background work through session teardown #11159 or Antigravity finishBackgroundCommands on interrupt-when-idle).
   3. Add a focused test: execute inProgress at end_turn with no later tool update must not pin Monitoring forever (or must clear on idle Stop).

   Related (same surface, not duplicates): #11680 (Grok leftover monitors), #11159 (banner Stop), #9139 (Grok monitor lifecycle), #7655 (completion vs live watch loop), #11428 (Stopping background work stuck Monitoring), #10164 (Monitoring notification hides Compact).
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 17, 2026
4. juliusmarminge

   closed this as completedin #13388on Sep 24, 2026