OpenClaw Adds Recovery for Tool Loops That Keep Changing Arguments but Make No Progress

OpenClaw merged a P1 agent-runtime fix into main on 27 July for a costly kind of tool loop: the model repeatedly calls the same tool with different arguments, but every call returns the same stable no-progress result.

Exact-argument loop detection could miss this pattern because each argument change appeared to create a new streak. Ordinary model and tool events also refreshed generic activity, allowing the run to look busy while accomplishing nothing. The merged work adds argument-churn evidence and routes the condition through OpenClaw’s recovery path.

This matters to unattended operators because a run can consume model calls, tool capacity and wall-clock time without tripping a simple repeated-call guard. The change is merged source work; the official packet does not identify a published package containing it.

Operator decision

Do not remove external budgets after upgrading. Loop detection is a recovery mechanism, not a universal proof that a run is productive.

Why exact-call detection was insufficient

A simple detector can notice this sequence:

find({query: "alpha"}) -> no matches
find({query: "alpha"}) -> no matches
find({query: "alpha"}) -> no matches

It is easier to miss this one:

find({query: "alpha"}) -> no matches
find({query: "alpha "}) -> no matches
find({query: "alpha*"}) -> no matches

The calls are not identical, but the evidence says the run is stationary: same tool, changing arguments, stable result, no useful progress.

The official commit summary shows that the implementation does more than compare adjacent calls. It refines churn evidence, reconciles rewritten arguments, preserves relevant clocks across policy waits, hardens concurrent policy tracking and avoids stale false positives before invoking recovery.

Interpretation: output stability is the important extra signal. Argument diversity by itself can represent sensible exploration. Recovery should trigger when those variations repeatedly fail to change the observed result, not merely because a model tries several inputs.

What operators should measure

Until the fix reaches your deployed package, monitor for combinations rather than one crude threshold:

• repeated calls to the same tool in one run;
• arguments changing without a corresponding state transition;
• identical or semantically stable error and empty-result output;
• model-token and wall-clock growth without completed work; and
• scheduled runs occupying lanes long enough to delay unrelated jobs.

Hard ceilings remain necessary: maximum run duration, model spend, tool-call count, subprocess timeout and queue-age alerts cover failure modes no semantic loop detector can recognize.

Acceptance test for the containing build

A useful staging suite should prove both detection and restraint:

1. repeated identical calls with stable output still take the established loop path;
2. varied arguments with the same no-progress result enter recovery;
3. varied arguments that produce genuinely different results are allowed to continue;
4. an approval or policy wait does not reset the evidence and create an infinite retry window;
5. concurrent tool activity does not attribute one run’s churn to another; and
6. recovery ends or redirects the run without duplicating consequential side effects.

Use read-only or disposable fixtures. A test for runaway behaviour should not repeatedly exercise a billing, messaging or deletion endpoint.

Scope and evidence limits

The pull request closes issue #112479 and is labelled P1 with availability and compatibility risk. The landed commit is 79c517df8942a8be26cb72f5c65a6dc9a49430ce. Its official summary records a substantial regression series around churn evidence, recovery, policy waits, concurrent tracking and stale false positives.

OpenClaw Academy did not independently run that suite or load-test the change. Web retrieval of the full pull request was unavailable, so this report does not invent detector thresholds, configuration keys or exact recovery messages absent from the official packet.

This fix also does not mean every repeated tool call is a bug. Pagination, polling and parameter search can legitimately revisit one tool. Operators should validate workflows where progress is external or not represented in the immediate result.

Bottom line

Changing arguments can disguise a stationary agent loop. OpenClaw main now looks for stable no-progress output across that churn and routes the run into recovery instead of treating every variation as fresh activity.

Adopt a confirmed containing build when available, but keep hard resource budgets. Semantic recovery reduces wasted work; independent limits stop the failures it cannot understand.