You just made the exact same tool call as your previous turn. This suggests you may be stuck in a loop. Please try a different approach or explain what you're trying to accomplish.

[manueloverride]

Model get's this all the time when builds fail.

It calls a script to build code. Script fails due to build error.
Model makes edit to source file.
Calls the same build script again.

Harness responds with the above message. Yes it is the same call, but the environment changed.

[Franck-Nein]

Had the same issue, ended up commenting out this part in

little-coder/.pi/extensions/quality-monitor/quality.ts

Lines 31 to 41 in e758baa

	// 3. Repeated tool call loop (exact name+input match with previous turn)
	if (toolCalls.length > 0 && recentToolCalls.length > 0) {
	for (const tc of toolCalls) {
	for (const prev of recentToolCalls) {
	if (tc.name === prev.name &&
	JSON.stringify(tc.input) === JSON.stringify(prev.input)) {
	return { ok: false, reason: "repeated_tool_call" };
	}
	}
	}
	}

It's not ideal since it won't stop the model when it actually gets stuck in a loop.

If you only want to allow some tools, you can probably do something like this:

+const repeatAllowedTools = new Set<string>(["Whatever", "tools", "you", "want"]);
 // 3. Repeated tool call loop (exact name+input match with previous turn) 
 if (toolCalls.length > 0 && recentToolCalls.length > 0) { 
   for (const tc of toolCalls) { 
     for (const prev of recentToolCalls) { 
       if (tc.name === prev.name && 
           JSON.stringify(tc.input) === JSON.stringify(prev.input)) { 
+          if (repeatAllowedTools.has(tc.name)) {
+            continue;
+          }
         return { ok: false, reason: "repeated_tool_call" }; 
       } 
     } 
   } 
 } 

[itayinbarr]

Fixed in v1.13.0. You diagnosed it exactly: the call is byte-identical, but the environment changed between the two, so it isn't a loop.

The quality monitor now skips its "repeated tool call" verdict when the previous turn also ran a state-changing tool (Edit/Write/Bash/ShellSession) alongside the repeated call — i.e. edit a source file, re-run the same build command, no false flag. A genuine loop (the same call again with nothing else changing) is still caught, so the guard keeps its value.

@Franck-Nein — this is a narrower version of your workaround: instead of exempting whole tool names (which stops catching a real Bash-only loop), it only exempts a repeat when something that could have changed the outcome ran next to it. Thanks both.

npm install -g little-coder@latest or /update. Closing as fixed.