Executor agent gets stuck in a loop when no action is possible

[FarhadMohseni]

Sometimes the executor agent loops forever when it can not do any action, especially when using liter LLMs for the executor (like google/gemini-2.5-flash-lite), the reason is there is nothing defined for the executor when no action is possible, for my case, I've edited the system prompt to use the wait action as "no-op".

I wanted to submit a PR but I was not sure whether it aligns with droidrun's system prompt guidelines.

Here is what I've added to my custom system prompt which fixed the issue:

### CRITICAL RULES ###
1. **ALWAYS OUTPUT A VALID ACTION** - Every response MUST include exactly one action from the atomic actions list below. There is no "skip" or "do nothing" option.

2. **NO LOOPS WITHOUT PROGRESS** - If you've tried the same action 2+ times and it keeps failing:
   - Try a DIFFERENT action or approach
   - If truly stuck, use `wait` with duration 1.0 and clearly explain why in the Description

3. **WHEN UNCERTAIN** - If you cannot determine what action to take:
   - Use `{"action": "wait", "duration": 1.0}` as a fallback
   - Explain in Description why you're waiting (e.g., "Waiting because subgoal is unclear" or "Element not found on screen") 

[0011Ashwin]

Thanks for raising this — I believe this exposes a real executor contract gap rather than a model-specific issue.

Root cause

**The executor is required to always respond, but there is no explicitly defined behavior when no valid action is possible (e.g., no actionable UI elements, repeated failures, or insufficient context).

With lighter LLMs (like gemini-2.5-flash-lite), this results in repeated “valid-looking” actions and infinite loops. This isn’t model misbehavior — it’s undefined behavior in the action protocol.**

Why wait as a no-op is correct

Treating wait as an explicit no-op aligns well with agent/RL environments and prevents the executor from hallucinating actions just to satisfy output constraints. Your proposed prompt rules are a good fix, but I think this should be formalized inside DroidRun itself.

Proposed PR-ready solutions

Option 1 (recommended):
Make wait a first-class fallback action in the default system prompt:

When no action is possible → wait(duration=1.0)

When uncertain → wait + explanation
This makes executor behavior deterministic under failure and model-agnostic.

Option 2:
Add a minimal executor-side loop guard:

Detect repeated identical actions without environment change

Force wait (or fail the subgoal) after N repetitions

Option 3:
Expose an explicit no_action_available environment state that requires the executor to emit wait.

Why this matters

Without this, DroidRun works reliably only with high-reasoning models, while lite models degrade into silent infinite loops. Formalizing a no-op action makes the framework more robust, debuggable, and model-independent.

I’m happy to submit a PR that updates the default system prompt and documentation (and optionally adds a small loop safeguard), depending on what best aligns with DroidRun’s design philosophy.

[FarhadMohseni]

@0011Ashwin Thanks for your reply, Let's see what the main maintainers think.

P.s: Even though this repo is all about AI agents, I miss some human touch in the issues, instead of directly pasting an LLM output as a reply!

[johnmalek312]

this seems like a solid approach to explain in description. the prompt looks too aggressive. Have you tried a simpler one sentence Use wait() when its unclear what next step should be or when you need to wait for ui change, use the description to explain whats unclear or what you are waiting for?

I believe this should work just as good without making the model think too much about it when the action is clear