You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Make doom_loop repeat threshold configurable #23531
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
permission.doom_loop is useful, but the current behavior appears to be hard-coded to trigger when the same tool call repeats 3 times with identical input. It would be helpful to make that repeat threshold configurable in opencode.json instead of fixed.
A configurable threshold would let users tune the guard for different workflows:
lower values for tighter cost/safety control in autonomous runs
higher values for iterative/debugging workflows where a few repeated retries are expected
A good direction would be to let permission.doom_loop accept staged thresholds directly:
That would allow progressive escalation instead of one fixed cutoff:
4+ repeated identical tool calls => ask
6+ repeated identical tool calls => deny
This feels more flexible than adding a separate top-level threshold field, because it keeps the behavior inside the existing permission system and supports multi-stage escalation naturally.
The exact config shape is up to you, but exposing the threshold this way would make the existing doom-loop protection much more practical.
Configurable thresholds would help, but I’d avoid making one magic number do all the work.
The same repeat count can mean very different things depending on whether anything changed. 4 identical calls + progress is usually fine; 4 identical calls + no file/state/verifier movement is the real danger. If you add staged escalation, I’d include that progress bit in the decision instead of only exposing a bigger/smaller threshold knob.
Activity
Keesan12 commentedon Jun 5, 2026
Configurable thresholds would help, but I’d avoid making one magic number do all the work.
The same repeat count can mean very different things depending on whether anything changed.
4 identical calls + progressis usually fine;4 identical calls + no file/state/verifier movementis the real danger. If you add staged escalation, I’d include that progress bit in the decision instead of only exposing a bigger/smaller threshold knob.github-actions commentedon Aug 5, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.