gemini-cli - 💡(How to fix) Fix Agent Enters Non-Functional Inaction Loop When Handling Self-Correction [1 comments, 2 participants]

What happened?

The agent repeatedly fails to execute promised actions after acknowledging its own incompetence. It enters a recursive │ │ loop where it: │ │ 1. Identifies a mistake. │ │ 2. Correctly describes the mistake and promises a specific corrective action (e.g., "I will now revert the │ │ rejection..."). │ │ 3. Receives user input confirming this is the correct path. │ │ 4. Fails to execute the promised action. │ │ 5. Instead, it either makes a different promise, or apologizes for its inaction, getting stuck in a meta-discussion │ │ about its failure to act. │ │ This results in a complete stall of the session, requiring repeated user intervention to break the loop. No tool calls are │ │ made.

gemini-conversation-1776012242574.json

What did you expect to happen?

After acknowledging an error and stating a specific, tool-based corrective action, the agent should immediately execute │ │ that action in the following turn. It should not get sidetracked by generating further explanations or making conflicting │ │ promises. The agent should follow a clear PLAN -> ACT -> VALIDATE cycle, even when the plan is to fix its own mistake. │

Client information

• CLI Version: 0.37.1
• Git Commit: 3b2d4f100
• Session ID: fbc22d72-7837-4fd3-84a4-f72889a590e9
• Operating System: win32 v24.11.0
• Sandbox Environment: no sandbox
• Model Version: gemini-2.5-pro
• Auth Type: oauth-personal
• Memory Usage: 1.08 GB
• Terminal Name: Unknown
• Terminal Background: #0c0c0c
• Kitty Keyboard Protocol: Unsupported

Login information

Login is via Google Account (oauth-personal).

Anything else we need to know?

The root cause appears to be a logical deadlock in the agent's reasoning when handling conflicting priorities. When a │ │ user directive ("Log this incompetence") is combined with the agent's self-generated plan to fix the underlying issue, the │ │ agent fails to create a stable, sequential task queue. It gets stuck trying to decide which promise to fulfill first, │ │ leading to total inaction. This suggests a failure in the core execution loop's ability to manage and execute a simple, │ │ ordered list of tasks when faced with self-correction and external feedback simultaneously.