OpenClaw Main Adds One Bounded Recovery Attempt for Critical Tool Loops

OpenClaw merged bounded recovery for critical embedded-agent tool loops into main on 6 August. When loop detection classifies a batch as critical, the runtime blocks that batch before tool execution, gives the model one opportunity to respond without tools and terminates the run if it reaches another critical loop.

The key word is bounded. The model gets one corrective chance, not an open-ended cycle of “detect, warn, retry.” The official pull-request record says this applies to embedded agents and adds no new configuration; native runtime behavior is not changed by this patch.

Operators running scheduled or unattended embedded agents should prioritize a containing release and test both recovery and terminal failure. Keep independent cost, duration and tool-call ceilings even after upgrading.

Operator decision

The reviewed evidence identifies a merged commit, not the published package version that contains it.

The recovery sequence

The intended sequence is deliberately small:

1. loop detection reaches a critical classification;
2. OpenClaw rejects the pending tool batch before execution;
3. the model receives evidence that a critical loop was blocked;
4. one tool-free recovery response is allowed; and
5. a second critical loop in the same run ends the run visibly.

This closes a nasty availability gap. Detection without a bounded terminal policy can itself become a loop: the runtime blocks, the model proposes the same behavior again and the system continues consuming model calls without performing useful work.

A single recovery attempt is a sensible compromise. Capable models can acknowledge the failure, change approach or explain the blocker, while persistent repetition does not gain an unlimited retry budget.

Why blocking before execution matters

A loop warning after a tool runs is too late for consequential actions. Repeated reads may waste money; repeated sends, writes or mutations can duplicate side effects.

The upstream change blocks the first critical batch before its tools execute. Your acceptance test should observe the tool owner or a disposable side-effect ledger, not just the text returned to the model.

For example, a mock message tool should show zero sends from the blocked batch. The recovery response may explain that the action was refused, but it must not quietly replay the same batch through another path.

Detection and recovery are separate controls

OpenClaw’s official loop-detection documentation describes detectors for repeated identical calls, no-progress polling and alternating pair patterns, with warning and critical thresholds. It also notes that rolling-window detection configuration is a separate concern.

Recovery does not make every unproductive run detectable. An agent can waste time through semantically different tools, repeated model-only reasoning, slow external waits or small actions that never cross a critical threshold.

Keep hard controls around:

• maximum run duration;
• tool-call count;
• model-token or cost budget;
• subprocess and network timeouts;
• duplicate-action idempotency; and
• queue-age alerts for blocked scheduled work.

Loop recovery is defense in depth, not a resource governor.

Acceptance tests

Use mocked or read-only tools.

1. Trigger one critical identical-call loop and verify the pending batch never executes.
2. Return a sensible tool-free explanation and verify the run can settle normally.
3. Force the model back into a second critical loop and verify terminal failure rather than another recovery cycle.
4. Place several calls in one batch and confirm none slip through after the critical classification.
5. Exercise retries and compaction so recovery state is not accidentally reset.
6. Confirm ordinary polling that demonstrates real progress is not classified as a critical loop.
7. Verify telemetry or logs distinguish warning, blocked recovery and terminal failure without recording sensitive tool inputs.

A good terminal result should be visible to the user or scheduler. Silent cancellation can turn a protected run into an operational mystery and invite manual duplicate execution.

Relationship to earlier argument-churn detection

OpenClaw previously added detection for a tool called with changing arguments while its output remained stably unproductive. This new change concerns what the embedded runtime does after critical evidence is established.

Interpretation: broader detection and bounded recovery solve different halves of the problem. Better detectors recognize more stationary behavior; a one-shot recovery contract prevents the detector’s response from becoming another unbounded control loop.

Scope and evidence limits

OpenClaw Academy reviewed the official merged pull request, commit summary and current loop-detection documentation. We did not independently run the embedded agent fixtures or verify detector thresholds. Upstream tests cover batch handling, retained evidence, retries and terminal recovery failures, but operators should reproduce the behavior with their own tool policy and runtime selection.

Bottom line

A critical loop now buys an embedded agent one chance to recover, not infinite chances to repeat itself. Upgrade to a confirmed containing release, verify the blocked batch has no side effects, and keep external budgets for the unproductive behavior no loop detector can see.