Symptom
The agent entered a dozens-of-turns loop answering the same user question.
Each replayed turn also injected a tool-use gate of the form: if a source path was named, the agent must read/edit that path before answering. Combined with turn replay, the agent kept read_file/codedb on the same docs and restating the same answer until the human interrupted.
Expected
After the question is answered from the named file, stop. Do not re-inject the same user question. The source-path gate should not fire on every subsequent turn when the prior turn already read (and, when needed, edited) that file.
Actual
The same user payload was replayed as a new turn many times (50+). Combined with the source-file gate, the agent kept:
- calling
read_file / codedb on the same spans
- repeating the same short answer
- getting the same question again
Why this is a harness bug
The user asked once. The session then replayed that turn plus a tool-use constraint that forced another read each time. That is session/prompt/turn scheduling, not the working repo.
Suggested fix
- Deduplicate consecutive identical user messages (or identical user+gate bundles) before injecting a new turn.
- The “named a source file → must read/edit” rule should be per unanswered mention, not re-applied after a successful read in the previous turn.
- If the gate must stay, fail closed after N identical loops and surface “stuck replay” to the user instead of burning the session.
Context
- Harness: Codegraff agent
- No secrets, credentials, or host details in this report (redacted from the original write-up)
Symptom
The agent entered a dozens-of-turns loop answering the same user question.
Each replayed turn also injected a tool-use gate of the form: if a source path was named, the agent must read/edit that path before answering. Combined with turn replay, the agent kept
read_file/codedbon the same docs and restating the same answer until the human interrupted.Expected
After the question is answered from the named file, stop. Do not re-inject the same user question. The source-path gate should not fire on every subsequent turn when the prior turn already read (and, when needed, edited) that file.
Actual
The same user payload was replayed as a new turn many times (50+). Combined with the source-file gate, the agent kept:
read_file/codedbon the same spansWhy this is a harness bug
The user asked once. The session then replayed that turn plus a tool-use constraint that forced another read each time. That is session/prompt/turn scheduling, not the working repo.
Suggested fix
Context