What happened?
While using Gemini CLI (v0.1.18) to move multiple component files and update their imports, the CLI incorrectly detected a “potential loop” and halted the request.
This happened during a repetitive but legitimate process:
Search for file references.
Move the file (git mv).
Search for import paths and update them.
The loop detection triggered despite no actual infinite loop occurring. The process was repetitive by nature (due to multiple files being handled), but finite.
Excerpt from session:
ℹ A potential loop was detected. This can happen due to repetitive tool calls or other model behavior. The request has been halted.
Gemini then stated it wasn’t truly stuck but was working through the list systematically.
What did you expect to happen?
The CLI should have allowed the repetitive-but-finite process to continue without prematurely halting due to false loop detection.
If the safeguard is triggered, there should be an option to confirm and continue when the user knows the process is intentional.
Client information
Details
CLI Version 0.1.18
Model gemini-2.5-pro
Sandbox no sandbox
OS win32
Auth Method gemini-api-key
Platform: Windows 10
Login information
No response
Anything else we need to know?
The CLI workflow was sequential and deterministic, not circular.
This behavior slows down bulk refactor operations where repetitive search/move/update patterns are necessary.
What happened?
While using Gemini CLI (v0.1.18) to move multiple component files and update their imports, the CLI incorrectly detected a “potential loop” and halted the request.
This happened during a repetitive but legitimate process:
Search for file references.
Move the file (git mv).
Search for import paths and update them.
The loop detection triggered despite no actual infinite loop occurring. The process was repetitive by nature (due to multiple files being handled), but finite.
Excerpt from session:
ℹ A potential loop was detected. This can happen due to repetitive tool calls or other model behavior. The request has been halted.Gemini then stated it wasn’t truly stuck but was working through the list systematically.
What did you expect to happen?
The CLI should have allowed the repetitive-but-finite process to continue without prematurely halting due to false loop detection.
If the safeguard is triggered, there should be an option to confirm and continue when the user knows the process is intentional.
Client information
Details
CLI Version 0.1.18
Model gemini-2.5-pro
Sandbox no sandbox
OS win32
Auth Method gemini-api-key
Platform: Windows 10
Login information
No response
Anything else we need to know?
The CLI workflow was sequential and deterministic, not circular.
This behavior slows down bulk refactor operations where repetitive search/move/update patterns are necessary.