Gemini creates a subtask, it does its job, but then it never stops, even if the task was just a “search a word”
it started running a npm run build and even a timer.
the previous timer was over, and started a new timer and another command. and the "Get-ChildItem still running.
Finished the previous timer and cargo build and the Get-childItem is still going. For no reason.
Hey @Luiz_Gabriel, totally feel this pain — and you’re not alone.
This is a known behavioral pattern that goes beyond just Gemini. What you’re seeing is a subtask lifecycle management problem — the agent spawns a process (like npm run build, cargo build, or even a Get-ChildItem), the process completes its purpose, but the agent has no clean exit condition wired to that completion. So it just… keeps going. Sometimes it even spawns new timers or commands as a kind of “keep-alive” behavior it wasn’t asked to perform.
Here’s what’s actually happening under the hood, and what you can do about it right now:
Why it happens:
No exit signal contract — Agents are designed to keep running until they receive an explicit “done” signal. When a long-running build finishes, the agent doesn’t always parse the exit code or stdout correctly to know it’s truly done — especially on Windows where PowerShell output formatting (like Get-ChildItem) can look ambiguous.
Heavy builds = timeout weirdness — cargo build and npm run build on large projects can take minutes. The agent’s internal timeout fires, it assumes the task is still running, and it restarts or chains new commands to compensate. This is the loop you’re seeing.
No task boundary awareness — The subtask model treats each command as potentially open-ended unless told otherwise. A simple search a word gets the same “keep watching” wrapper as a 10-minute compilation.
What actually helps right now:
Add explicit completion markers in your prompts. Tell the agent: “When cargo build exits with code 0 or 1, stop. Do not run any further commands.” This sounds obvious but it genuinely constrains the behavior.
Use timeout wrappers. On Windows: Start-Process -Wait cargo -ArgumentList 'build' — this ensures PowerShell itself signals termination. On Linux/Mac: timeout 300 cargo build.
Pre-define your task boundaries in a .md rule file (as you mentioned — this is genuinely solid advice). Something like:
# Agent Rules
- After any build command, await exit code and STOP.
- Do not spawn timers unless explicitly instructed.
- Max subtask duration: 5 minutes. Kill and report if exceeded.
cargo build --message-format=json which gives cleaner, parseable output that agents handle far better than raw terminal formatting.The bigger picture:
This isn’t a bug that’ll be “patched” quickly because it’s architectural — it sits at the intersection of how agentic loops handle process I/O, OS-level signals, and the model’s uncertainty about task completion. Until agent frameworks build proper process lifecycle hooks (spawn → monitor → confirm exit → close subtask), workarounds like the ones above are your best bet.
The good news? As agentic tooling matures (and yes, faster inference helps reduce the timeout-related chaos), these patterns are actively being addressed. But right now, the most reliable solution is you being explicit — the more precisely you define “done,” the less room the agent has to wander.
Hope this helps and saves you some tokens! 
Hi @Luiz_Gabriel_dos_San, Welcome to the Forum!
To help us investigate why the agent is getting stuck in an execution loop instead of terminating, please share a few details:
Version & OS: Your specific Antigravity version and Operating System
Task Scope: Does this happen on all tasks, or only on specific types?
Exact Prompt: The specific task or prompt you gave Gemini that triggered the issue?
Antigravity is at v2.1.4, and i’m using Windows 11, also up to date in updates.
As for scope, this is kinda hit or miss. It’s always a “choice” of the model to do those scripts to find some specific document or a word in a document, so that command is not part of the original prompt, like “The chatbot is not working, [screenshot image here] look for what is causing this and fix it” and then those “Get-ChildItem” or other commands like that are just substeps of the model trying to navigate the code and find the culprit. But the problem is, 1/3 of the time it doesn’t finish it after the script found the answer it was looking for. So it’s more like, the model sometimes doesn’t format it’s own steps correctly and forgets to give it an ending condition.
And the prompt was something along those lines. But it is a very recurring problem. if I find it again I’ll put the new example.