Repository navigation
Agent gets stuck in a tool-call loop, repeating the same action and wasting tokens #43800
Description
Description
The agent (opencode CLI, model deepseek-v4-flash) intermittently enters a tight loop where it re-emits the same tool call over and over instead of completing it once and moving on. Each repetition produced no new progress, and I had to interrupt it manually each time. This happened multiple times in a single session and caused severe token/billing waste and blocked progress.
Notably, the loops were not all identical in trigger — some were repeated file reads, some were repeated git commit/git add attempts, some were repeated git status checks — but in every case the agent re-issued an identical call instead of executing once and proceeding.
Steps to reproduce
- Start a long, multi-phase task that requires many sequential tool calls (file reads, edits, git commits, test runs).
- Drive the task through several completed steps.
- At some point the agent re-emits the same tool call repeatedly (observed: repeating a
readof the same file, or repeating agit commit, or repeating agit status) with no new output. - It does not self-correct or proceed until interrupted.
Not always deterministic — the task sometimes proceeds normally for a while, then enters a loop.
Expected
Each tool call executes once; the agent proceeds to the next logical step.
Actual
The identical tool call is re-emitted in a tight loop; progress stalls; each repetition consumes tokens.
Impact
Severe token/billing swell and blocked progress on real work.
Environment
- OpenCode version: 1.18.19
- Model: opencode-go/deepseek-v4-flash
- OS: macOS 25.5.0 (Darwin 25.5.0), Apple Silicon (ARM64, T6020)
- Node.js: v26.5.0
- Terminal: (macOS default)
- Plugins: none
Activity
github-actions commentedon Aug 21, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is the same, consider adding a comment there with your specific details rather than a new report.
agentgoblin commentedon Aug 27, 2026
How about
doom_looppermission? #45442 (comment)jagnd1 commentedon Aug 29, 2026
Closing this as resolved — the loop class I reported is covered by the existing
doom_looppermission, which I wasn't aware of when filing.Evidence (tested on opencode 1.18.20, deepseek-v4-flash):
"permission": { "doom_loop": "deny" }inopencode.json.ls -lacommand five times.Error: The user has specified a rule which prevents you from using this specific tool call. ... [{"permission":"doom_loop","action":"deny"}], and the session ended with no further token burn.So the missing piece wasn't a new detector —
doom_loop(same tool call repeated 3× with identical input) already exists but defaults toask, which doesn't protect unattended/--autosessions. Setting it todenygives the hard circuit-breaker. Anyone hitting the identical-tool-call loop should setdoom_looptodeny(oraskif they'd rather be prompted).Thanks to @agentgoblin for the
doom_looppointer (#45442) and to the maintainers for triaging. Happy to reopen if a loop class outside identical-input detection still reproduces (e.g. calls that vary slightly but never converge).