Agent re-reads same files and re-runs identical SQL queries within a single turn
- 主要言語
- 言語のデータがありません
- スター
- 2.1k
- フォーク
- 153
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
**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.
コントリビューションガイド
評価
この issue はまだ評価されていません。