Repository navigation
v1: repeated tool calls across assistant messages bypass doom_loop deny #60448
Description
Description
In v1, identical tool calls across separate assistant messages bypass doom_loop, including an explicit session rule setting it to deny. The processor checks only the current assistant message, so a model issuing one tool per response never reaches the three-call threshold.
This is the maintained-client counterpart of the repeated-call problem in #45442. Open PR #53032 targets dev and its newer core implementation.
OpenCode version
v1 at 006d837c5022ea5278162307c04c78412cfae9f3 (1.19.5 source).
Steps to reproduce
Use a local synthetic provider to return four identical tool calls in four assistant responses, followed by a terminal text response. Configure the session with an allowing general rule and doom_loop: deny.
Four identical failed edits still execute. A repeated shell command appending a marker in a disposable directory provides an observable execution count.
Expected: the existing permission gate applies on the third identical call across assistant messages. Deny must prevent that execution; allow must keep permitting it. A new user message resets the history, and continue_loop_on_deny retains its existing meaning.
OS
macOS, arm64; bounded local-provider tests without paid API calls.
Activity
opencodejr commentedon Oct 30, 2026
Thanks for the detailed report and the bounded repro.
This is about OpenCode v1, which only gets fixes for critical bugs such as data loss, security problems, or crashes with no workaround. The repeated calls here are already allowed by your general permission rule, and you can stop a runaway loop by interrupting the session or setting a step limit. So it's unlikely this will be fixed in v1. The same root cause was reported in #51965 and closed for the same reason.
Please upgrade to v2 (
@opencode/cli), where active work happens. v2 doesn't currently have a cross-stepdoom_loopcheck either. That work is tracked here:dev)If you believe this is critical in v1, or you see it in a way those issues don't cover on v2, please reply here.
opencodejr commentedon Oct 31, 2026
We haven't heard back, so I'm closing this as not planned. This
doom_loopgap is in v1, which only gets fixes for critical bugs, and the same root cause was closed for that reason in #51965. The v2 work on loop protection is tracked in #59339 and #45442, with PR #53032 targetingdev. If you see repeated tool-call loops on v2 that those issues don't cover, please open a new issue with your v2 version and repro steps. Thanks again for the careful report.