[BUG] Infinite looping

[jcalfee]

Problem (one or two sentences)

After the bot finishes it goes into an infinite loop.

Context (who is affected and when)

me, most of the time

Reproduction steps

chat with a bot

Expected result

work

Actual result

not work

Variations tried (optional)

No response

App Version

3.47.3

API Provider (optional)

Google Gemini

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

Roo said
思: The code looks correct.
I'll complete the task.
I'll mention that I verified with tests and then reverted them.
I'll also mention that I handled run specifically as requested, and other commands use the standard append logic.
I'll use attempt_completion.
I'll make sure to be brief.
"I've updated packages/rev18/envar/src/env-runner.js to inject arguments immediately after the run command, while appending them for other commands. I verified this with tests (which I then reverted)."
This is concise and accurate.
I'll use attempt_completion.
I'll double check if I need to do anything else.
No.
I'll use attempt_completion.
I'll wait for the user's response.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.
I'll use attempt_completion.

[jcalfee]

@roomote also:

思: The code is correct.
I'll complete the task.
I'll mention that I verified with tests.
I'll mention that I reverted the tests.
I'll mention that the fix is in packages/rev18/envar/src/env-runner.js.
I'll mention that it injects arguments immediately after the command.
I'll mention that this handles both explicit -- and implicit command starts.
I'll mention that this supports get command as well.
I'll mention that I verified with tests.
I'll mention that I reverted the tests.
I'll mention that I verified with tests.
I'll mention that I reverted the tests.
I'll mention that I verified with tests.
I'll mention that I reverted the tests.
I'll mention that I verified with tests.
I'll mention that I reverted the tests.
I'll mention that I verified with tests.
I'll mention that I reverted the tests.
I'll mention that I verified with tests.
I'll mention that I reverted the tests.
...

[roomote]

I've seen your comment and will explore a potential fix for the infinite looping issue in reasoning/thinking output. The pattern you're describing - where the model's thinking gets stuck repeating the same lines - appears to be a gap in the current repetition detection, which only checks tool calls but not reasoning content. I'll open a PR to share progress.

[roomote]

I've analyzed this issue and here's what I found:

Root Cause Analysis

The infinite loop happens when a model (particularly Google Gemini) produces only reasoning/thinking tokens without any text content or tool calls. Looking at the logs, the model's thinking gets stuck repeating "I'll use attempt_completion" but never actually outputs a tool call.

In the codebase, there are two code paths when a model response completes:

Path 1: "No tools used" (model produces text but no tool calls) - in Task.ts

• Increments consecutiveNoToolUseCount, and after 2 consecutive failures, increments consecutiveMistakeCount
• Eventually triggers consecutiveMistakeLimit (default 3) which shows the "mistake_limit_reached" dialog
• This path has proper safeguards

Path 2: "No assistant messages" (model produces only reasoning tokens, no text and no tool calls) - in Task.ts

• Increments consecutiveNoAssistantMessagesCount and shows an error after 2 failures
• But does NOT increment consecutiveMistakeCount, so consecutiveMistakeLimit is never triggered
• With auto-approval enabled, this retries indefinitely with backoff -- an infinite loop
• Without auto-approval, shows an "api_req_failed" dialog on every retry, requiring manual dismissal each time

The reasoning-only case is treated as an empty response error rather than what it actually is: the model got stuck in its thinking and failed to produce actionable output.

Proposed Implementation Plan

1. Add consecutiveMistakeCount increment to the "no assistant messages" path in Task.ts -- after the 2nd consecutive failure (matching the grace-retry pattern), increment consecutiveMistakeCount++ so the consecutiveMistakeLimit check at line 2695 can eventually stop the loop.

2. Treat reasoning-only responses as "no tools used" instead of "no assistant messages" -- when the model produces reasoning tokens but no text or tool calls, the system currently treats it as a completely empty response. A better approach: check if reasoningMessage has content, and if so, treat it as a "has content but no tools" case (Path 1), which already has proper safeguards. This change would be at line 3478, modifying hasTextContent to also consider reasoningMessage.length > 0.

3. Add tests to verify that:

   • Reasoning-only responses eventually trigger the mistake limit
   • The "no assistant messages" path now counts toward consecutiveMistakeCount
   • Auto-approval does not cause infinite retries in either scenario

Approach (2) is the more precise fix since it correctly identifies that the model DID respond (with reasoning), it just failed to produce actionable output. Approach (1) is a safety net for the truly empty response case. I'd implement both.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[roomote]

Opened PR #11338 with my attempt at addressing the repetitive reasoning loop issue. The fix adds a ReasoningRepetitionDetector that monitors the model's thinking/reasoning stream in real-time. When it detects the same line repeated 5+ times, it aborts the stream early to save tokens and gives the model guidance to try a different approach. This should catch the exact pattern described in this issue. Feedback welcome!