Repeat-tool reminder detects loops but does not reliably break them

[bilalzubairAI]

I’m testing DeepSeek Harness 0.1.5-rc.2 with a local OpenAI-compatible provider:

Harness: 0.1.5-rc.2
Model: Qwen3.8-27B-exl3-8.00bpw
Backend: TabbyAPI
Tool format: qwen3_coder
Context: 262144

I’ve run into a repeated tool-call loop where Harness correctly detects the repetition and injects a repeat-tool-reminder, but the model continues issuing essentially the same tool call anyway.

Example from one task:

Read BayComposer-private-alpha-stabilization\tests\qt_test_lifecycle.py

Grep def release

Read BayComposer-private-alpha-stabilization\core\playback_service.py

Grep def test_
Grep def test_
Grep def test_

Context injection repeat-tool-reminder grep × 3

Grep def test_

Read BayComposer-private-alpha-stabilization\docs\ROADMAP.md

Grep PSA-001|PSA-002|PSA-003

Grep def test_
Grep def test_
Grep def test_

Context injection repeat-tool-reminder grep × 3

Grep def test_
Grep def test_

Context injection repeat-tool-reminder grep × 5

The loop detector is clearly working, but the recovery behavior appears too weak. The reminder is injected, yet the model still falls back to the same broad search instead of synthesizing the evidence already collected or changing strategy.

Expected behavior

After repeated identical or near-identical tool calls are detected, Harness could do something stronger, such as:

deduplicate or block the same tool call after N repetitions
force a “summarize what you already know” step
require the model to state what unresolved information it is trying to obtain before another repeated tool call
suppress broad searches when the same query has already been exhausted
redirect the agent toward exact-symbol/file inspection instead of repeating a repository-wide grep
track exhausted search paths within the task
Actual behavior

Harness detects the repeated calls and injects reminders, but the model can continue the same loop anyway.

Why this matters

On large coding tasks, especially with long-context local models, this can waste substantial context and time even though the needed information may already be present in the task history.

Manual intervention fixes it easily. For example, telling the model:

Stop repeating searches that have already returned the same evidence. Use the information already collected and only search for a specific unresolved symbol.

usually breaks the loop immediately.

So the issue seems less about loop detection and more about loop recovery / enforcement.

It would be useful if future Harness versions could turn the existing repeat-tool detection into a stronger automatic recovery mechanism.

I found a few related discussions after posting this, especially #5072 and #5540. My case seems slightly narrower: repeat-tool-reminder did detect the exact repeated tool call and injected reminders at ×3 and ×5, but the model still continued issuing the same grep def test_ call.

So this appears to demonstrate the “advisory only” limitation directly: detection worked, but recovery/enforcement did not. A possible improvement would be an optional high-threshold hard block or forced “synthesize existing evidence before another tool call” step after repeated reminders fail.

[argszero]

Your diagnosis is right, and the fix is already sanctioned upstream — the guard's own README lists it as a known, unimplemented limitation:

Advisory only — escalating to a blocking form at a high threshold is not implemented, though PostToolDecision already supports blocking.

So the detection is working as designed; the enforcement tier was simply deferred. Two things are worth separating, because they have different causes.

1. Why the reminder does not change behaviour. The reminder is delivered as an ordinary user/message with source.kind:'plugin' after the repeated call's result (repeat-tool-reminder/src/index.ts:203-206). To the model that is one more sentence of context competing with the whole task; nothing about the repeated call changes, so if the model's plan says "search again", it searches again. Your log is the clean demonstration: the reminder fires at 3, the model repeats, it fires at 5, the model repeats again.

2. The part that is easy to miss, and it explains the tail of your log. The same README adds:

Past the highest threshold a chain goes silent — reminders fire only at exact configured counts, never beyond them.

The default thresholds are [3, 5, 8] (repeat-tool-reminder/src/index.ts:46), and reminders fire only at exact counts (:199). So the 9th, 10th, and 11th identical calls produce no reminder at all. The later iterations of your loop were unguarded — the model had already proven it was not responding to advice, and the advice had run out.

The enforcement boundary is real, and it is not PostToolDecision. Both available levers are already implemented in the tool pipeline:

• tools/pre-execute → { kind: 'deny', reason } — the call is never dispatched; the registry materializes the error and returns without reaching the tool body (tools/src/index.ts:1479-1489).
• tools/post-execute → { kind: 'block', feedback } — the call already ran, and the result is turned into an isError (tools/src/index.ts:1738-1746).

That difference matters for your case. A block still executes the search and still costs a full model turn before the model sees a failure, so a determined loop survives it. A pre-execute denial removes the round trip entirely: the repeated action stops producing a result to react to.

PreToolDecision cannot rewrite the arguments (documented at tools/src/index.ts:576-580, "input rewriting is excluded because arguments are already logged and presented"), so your suggestion #1 — "deduplicate or block the same tool call after N repetitions" — is the shape that is actually available, and #4 ("suppress broad searches when the same query has already been exhausted") is the same lever applied to a query class.

I published the enforcement tier as a plugin:

@argszero/cordis-plugin-repeat-guard-escalation (repo)

dsh plugin add @argszero/cordis-plugin-repeat-guard-escalation

It counts the same chains the shipped guard counts and, from escalateAt (default 9 — one past the highest reminder threshold, so every escalation is preceded by a reminder that was ignored), denies the call before dispatch with text that says what to do instead:

Blocked: `grep` has now been called with identical arguments 9 times in a row, and the
reminder you were given did not change the outcome. The results of those calls are already
in this session — do not issue this call again with these arguments. If the evidence you
already have is enough, answer or make the change now. If it is not, the missing piece is
specific: say what it is, then either use a different tool or narrow the arguments so they
target exactly that piece.

The reminder is untouched — the shipped guard still runs and still explains itself.

Three deliberate limits, since a guard that traps the session is worse than the loop it prevents:

• Bounded. At most maxDenials (default 3) denials per chain, then it steps aside permanently and calls proceed. Your "manual intervention fixes it easily" line is the reason this is bounded rather than absolute — enforcement should end the loop, not the session. The final denial says so explicitly, so the model knows the block is ending.
• Exact repeats only. The chain key is [toolName, canonicalArguments] with deep key-sort, identical to the shipped guard's (:194-195). A different call resets the chain and a user message clears it, so a legitimately repeated idempotent call never escalates.
• Chains stay per-agent, matching the existing behaviour, so a parent and subagent repeating the same call never combine counts.

22 tests pass (11 pure-rule + 11 against the real dsh-tools registry); the integration tests assert the decisive property directly — after a denial, the tool body's execution counter does not move.

On your point that this is "less about loop detection and more about loop recovery": agreed, and that is how it is built. The guard's detection was never the problem; the missing piece was that nothing happened after the advice was ignored.

[bilalzubairAI]

I hit a second variant of the same recovery problem, this time with the Edit tool rather than grep.

The agent repeatedly submitted an invalid edit where old_string and new_string were identical. Harness returned the deterministic error:

old_string and new_string must differ

but the agent continued retrying the same failed Edit call many times instead of re-reading the target region, reconstructing the patch, or recognizing that the intended change might already be present.

So this looks like the same broader issue from a different angle:

loop detection / failure detection exists
but recovery is not strong enough
deterministic tool failures can still be retried repeatedly

A stronger recovery path could be:

detect repeated identical failed tool calls,
block the same call after N failures,
force a targeted reread / state refresh,
require a materially different tool input before retrying,
or force the agent to stop and report the unresolved edit.

This occurred on 0.1.5-rc.2 with the same local Qwen3.8 / TabbyAPI setup as the original report.

[argszero]

This is the same class of failure from a different angle, and you have put your finger on the important half: detection is not the missing piece, recovery is.

I checked the shipped guard against your case and your diagnosis holds exactly. guard/repeat-tool-reminder counts calls at tools/pre-execute and injects text at tools/post-execute — but it never inspects the result. It has no notion of whether the call it just counted succeeded or failed. So a deterministic error gets precisely the same gentle advice, at precisely the same late thresholds, as a legitimate poll loop. Worse, reminders fire only at exact configured counts, so with the default [3, 5, 8] the ninth and later identical calls draw nothing at all.

That last point matters for your Edit case: the model was already past the point where the guard had anything to say, and the guard would not have said anything different even if it were still speaking.

I have shipped this as v0.1.1 of the plugin from the first half of this thread, @argszero/cordis-plugin-repeat-guard-escalation. It now escalates the two shapes separately:

• a repeated success keeps the advice-first threshold (escalateAt, default 9) — a poll loop may be legitimate, so it should get its chances;
• a repeated failure is denied far earlier (escalateFailingAt, default 3), because retrying unchanged arguments against the same deterministic error cannot work by construction.

The denial quotes your error back verbatim, since that is what the next attempt has to be aimed at:

Blocked: `edit` has now been called with identical arguments 4 times in a row,
and the last 3 of them failed with the same error. Repeating it cannot succeed —
the tool is not going to accept these arguments on the next attempt. The failure
was: old_string and new_string must differ. Change the arguments so they no
longer trigger it, or use a different tool. If the change you intended may
already have been applied, read the target back before editing it again.

Two honest notes on the design, because both are deliberate:

1. escalateFailingAt counts observed failures, so the default of 3 lets three failing calls through and refuses the fourth. Whether an in-flight call will fail is not knowable before it runs, and assuming it would be exactly the false positive the guard exists to avoid. This is the one asymmetry with escalateAt, which counts the call it is about to deny.
2. It denies; it does not rewrite your arguments into a "forced targeted reread". A guard that invents new arguments is guessing at your intent, and a wrong guess at the write path is worse than the loop. Refusing the call and naming the error is the strongest move that stays correct.

Enforcement remains bounded (maxDenials, default 3) so a looping session can still finish.

One correction worth recording, since it affects anyone building on these seams — and it corrected my own first version's documentation. I had written that a denied call never reaches tools/post-execute. That is false:

• the deny path materializes a post-result (packages/core/tools/src/index.ts:1479-1489) rather than a final-result;
• every post-result is routed through finalizeScheduledExecution → postExecute (:1345), a property documented at :420-421;
• I confirmed it by probe on both 0.1.2-rc.1 and 0.1.5-rc.2: the denied call's third post-execute observation arrives with isError: true.

Deny still skips dispatch, which is why it remains the right lever — the repeated side effect does not happen and no model turn is spent on it. But the call's result is still observable, which is what let me build the failure tier on top of deny, and also means a plugin must be able to recognise its own denials: otherwise it reads its own refusal text as the tool's error and escalates against itself. The two seams share the exec object by reference, so that recognition is exact rather than a string match.

Of your five suggestions: (1) detect repeated identical failures — done, this is the escalateFailingAt tier; (2) block the same call after N failures — done, via deny, which is stronger than a post-execute block because the call never executes; (4) require materially different input before retrying — that is exactly what changing the arguments does, and it is what the denial text asks for; (3) force a targeted reread and (5) force a stop-and-report are the two I deliberately did not implement, for the reason in point 2 above — both require the guard to author content or terminate work on the model's behalf. If you want either as an opt-in, say so and I will look at it, but I would rather not have it on by default.

Verification: 32/32 tests, including a deliberately mutation-checked case that fails if the plugin ever counts its own denial as a tool failure. The published artifact was installed into an empty project and exercised on 0.1.2-rc.1, 0.1.3-alpha.2 and 0.1.5-rc.2 — your line, running the same edit shape: calls 1–3 reach the body and fail, call 4 is refused with the body counter unchanged.

npm install @argszero/cordis-plugin-repeat-guard-escalation

If you deploy it on your Qwen3.8/TabbyAPI setup, the number worth watching is whether the failing-edit chain now stops at 4 instead of running on — and if it still runs on, that is a bug in my counter and I would want the log.