Agent re-reads same files and re-runs identical SQL queries within a single turn
- Langage dominant
- Aucune donnée de langage
- Étoiles
- 2.1k
- Forks
- 153
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
**Affected version**: 0.2.18 (embedded CLI engine 1.0.56-2)
**Installation context**: Desktop app on Windows 11
## What happened?
Within a single user turn, the agent repeatedly invokes the same tool with the same (or near-identical) arguments instead of using cached results. Pulling from my cloud session store, I found multiple recent sessions exhibiting this in different shapes. Three representative examples:
### Example 1 — extreme single-turn fixation (worst case)
Session `7f2fe649-1aa2-4823-ab24-32d0b3e9d2b0` — **1 turn total**:
- **224** `view` calls on a single file (`C:\Users\toegbeji\Wiki\AGENTS.md`)
- **42** `view` calls on a second file (`C:\Users\toegbeji\.copilot\copilot-instructions.md`)
- 29 + 19 + 6 `report_intent` calls with identical intent strings ("Confirming wiki ingest workflow", "Reading wiki AGENTS.md", "Confirming instruction files")
No path-separator variation — every call used the same exact `arguments_json`. This is pure pathological re-reading: the agent could not move past re-confirming instruction files.
### Example 2 — direct evidence of a path-normalization bug
Session `1d3a2b57-319e-4ac9-8c39-516531f7315c` — 36 turns:
The same file was read repeatedly under **two different cache keys** that differ only in path separators. For example:
| File | `C:\…` form | `C:/…` form |
|---|---|---|
| `…\checkpoints\001-resuming-bucket-b-az4-cleanup.md` | 35 reads | 31 reads |
| `…\files\bucket-b-triage-batch-2.txt` | 31 reads | 28 reads |
Across this session, **19 distinct files** were each accessed under both backslash and forward-slash forms (68 raw distinct `view` arg strings collapsing to 49 unique paths after normalization). Any "have I already called this?" check based on the raw `arguments_json` string would miss every one of these duplicates.
### Example 3 — the original session that prompted this report
Session `3b80aea3-b9fc-4fcd-997a-e58bcf6e14e0` — 3 turns:
- 54 `view` calls against only **2 unique files** (each read 27 times)
- 49 `sql` calls, top query repeated **12 times byte-identical**
- 2 of the read files showed the same backslash/forward-slash collision as Example 2
- The user's turn-2 message was literally "Now you're looping"
## Steps to reproduce
Not reliably reproducible on demand. It surfaces during multi-step work that mixes `view`, `grep`, `sql`, and `report_intent` over the same small file set — particularly when paths can be expressed both with `\` and `/` on Windows. The three session IDs above can be inspected via the session store.
I have not observed this loop pattern when using the standalone `copilot` CLI in a terminal — only in the desktop app, even though the underlying engine (`Copilot CLI` agent identity) is the same.
## Expected behavior
Within one turn, the agent should not re-invoke the same tool with semantically identical arguments. Repeated reads of an unchanged file or repeated runs of an identical query should be served from an in-turn cache. The cache key should be normalized so that `C:\foo\bar.md` and `C:/foo/bar.md` collapse to the same entry on Windows.
## Additional context
- Related (auto-generated feedback, no diagnostic detail): #200, #396, #581
- [Inference] Suggested mitigation: per-turn dedup of identical tool calls, with normalization of path arguments (forward/back slash, case on Windows) before the equality check. Example 2 above is direct evidence that lack of path normalization alone is causing duplicate reads; Example 1 shows that something stronger (a hard cap or an in-turn cache even for byte-identical args) is also needed because path normalization wouldn't have helped there.
- Agent identity in all three sessions was `Copilot CLI`, so the engine is shared with the terminal CLI; the loop manifests in the app context but not (in my usage) in the terminal.
Guide de contribution
Ouvrir le guide de contribution
Évaluation
Cette issue n'a pas encore été évaluée.