Continue repeats identical tool calls instead of bounding the loop

[trackoor]

Continue repeats identical tool calls instead of bounding the loop

Before submitting your bug report

• I checked for duplicate local reproduction drafts.
• I reduced the reproducer to a single deterministic local-provider case.

Relevant environment info

• OS: Linux x86_64 Docker
• Continue version: @continuedev/cli 1.5.46
• IDE version: CLI (cn), no IDE
• Model: OpenAI-compatible local mock provider, gpt-4

Description

Severity / performance impact: High. A repeated tool-use response can cause multiple committed tool side effects and repeated provider turns.

To reproduce

Prerequisites: Docker, Python 3, and the GitHub CLI (gh) for the clone command below. The linked reproducer is self-contained and uses only Python standard-library modules plus Docker. It builds the affected CLI version from the public package registry, starts a local mock provider, and runs the CLI in an isolated workspace. The Docker run is limited to 2 CPUs and 4 GiB RAM by default.

Complete self-contained reproducer: https://gist.github.com/N0zoM1z0/c166065dd2a35dfdbd634ee447460579

The Gist contains continue-repeated-identical-tool-loop.reproduce.py. Download and run:

gh gist clone c166065dd2a35dfdbd634ee447460579 continue-repeated-identical-tool-loop-reproducer
cd continue-repeated-identical-tool-loop-reproducer
python3 continue-repeated-identical-tool-loop.reproduce.py

To reuse an already-built local image:

python3 continue-repeated-identical-tool-loop.reproduce.py --skip-build

Expected successful reproduction output includes:

REPRODUCED

Log output

Expected successful reproduction output includes REPRODUCED.

Observed behavior: The local provider repeats a shell tool call after tool results arrive. The script checks for at least two side-effect log entries.

Expected behavior

Continue should detect repeated identical tool-use state and stop with a bounded error rather than executing the same work repeatedly.

Public-upstream status

This reproduces against stock public @continuedev/cli@1.5.46 built from npm.

[cschanhniem]

This issue + #12701 (post-cancel execution) and #12700 (unbounded stdout) form a coherent pattern: Continue's agent mode lacks a policy enforcement layer between the model's tool-use output and the filesystem. The LLM can emit tool calls, but there's no gate checking "should this action proceed?"

Three governance levers every AI coding tool needs at the tool-execution boundary:

1. Idempotency guard — detect identical consecutive tool calls and halt (this issue)
2. Cancellation integrity — flush pending tool effects on interrupt (Continue can execute a tool effect after SIGINT cancellation #12701)
3. Output bounding — cap tool result size before it enters the context window (Continue returns an unbounded huge stdout tool result #12700)

This is exactly the problem space we built AGENTOWNERS (https://github.com/agentcontrol/agentowners) for. It's a deterministic policy engine (CODEOWNERS for AI agents) that defines what agents may do at the repo level. For Continue's tool-execution model, the integration pattern would be:

• require_approval ai_agent action=shell_exec pattern="rm|git push|npm publish" — dangerous commands need human sign-off
• block ai_agent action=file_write glob=".env,.git/config,*.pem" — files agents must never touch
• warn ai_agent condition="consecutive_identical_tool_calls > 2" — catch runaway loops

The key is that this runs deterministically — no LLM calling another LLM. Policy file → evaluation → decision in under 50ms. Would integrate as a middleware in Continue's tool dispatch pipeline before executeCommand reaches the shell.

Happy to collaborate on how this integrates with Continue's tool registry in core/nextEditHandler/tools/.

[HarperZ9]

I published a small synthetic fixture for the loop-boundary version of this issue.

The case is loop_guard_idempotency: repeated identical
ead_file calls are reduced to a canonical tool-call fingerprint ( ool_name, canonical_args_hash, workspace ref, side-effect class), the guard records identical_tool_call_count, max_identical_tool_calls, terminal status, and stop reason, and the expected outcomes separate
epeat_tool_call_blocked from guard_missing.

Fixture: https://github.com/HarperZ9/telos/blob/e12425b/demo/integrations/agent-boundary-fixtures.json
Verifier: https://github.com/HarperZ9/telos/blob/e12425b/demo/agent-boundary-fixtures.test.mjs

The acceptance-test shape I would want is not just "the model eventually stops." It is: the runner can prove it saw the same tool+args fingerprint exceed a bounded threshold, blocked before another filesystem action, and emitted a durable receipt explaining why.