Debugging-loop-hint false positive: fires even when each consecutive failure has a different root cause (error output changed = progress, not a loop)

Description

The debugging-loop-hint system message fires based on counting repeated invocations of the same command string, regardless of whether each attempt actually made progress. This produces false positives that add noise in exactly the situation where iteration is legitimate: environment-dependent failures where each fix changes the error.

Repro (real session, 2026-08-24)

One compile command (wsl bash bench_ab.sh via PowerShell host) failed 3 times in a row, with a different root cause each time:

1. cc1: fatal error: .../chipwork/bench_plugin.c: No such file or directory → script had a wrong source path. Fixed.
2. implicit declaration of function 'clock_gettime' → -std=c11 strict mode hides POSIX declarations; needs -D_GNU_SOURCE. Fixed.
3. ld: cannot open output file /tmp/chipbuild/bench_plugin → WSL /tmp was cleaned between tool calls; needed mkdir -p. Fixed.

Each failure was progress — the error line changed, each fix addressed a proven cause. Yet after the 2nd attempt the hint already scolded "repeatedly re-running the same failing command... instead of proposing another hypothesis", which is precisely what I was doing correctly (reading each new error, fixing one verified cause at a time). The command then succeeded on the 4th run and produced valid benchmark results.

Why the current heuristic misfires

It treats "same command string, N failures" as a loop. But an unchanging command is expected during bring-up of build scripts; what distinguishes a real loop from progress is whether the failure mode changed:

• Real debugging loop: same error output repeated, agent keeps editing source on guesses.
• Legitimate iteration (this case): error output differs every attempt because each fix lands.

Suggestion

Before firing, compare a normalized signature of the most recent error output against the previous attempt:

• If the error signature is unchanged across ≥2 consecutive failures → fire the hint (current behavior).
• If the error signature changed since last attempt → reset the counter; the agent demonstrably responded to evidence. Optionally still fire at a higher threshold (e.g. 5+ attempts even with changing errors).

This keeps the guardrail for genuine loops while eliminating false positives during normal environment/build-script debugging.

Environment

• opencode CLI on Windows (PowerShell 5.1 host) driving WSL commands
• Model: any (behavior is harness-side, not model-side)