Skip to content

[FEATURE]: Make doom_loop repeat threshold configurable #23531

Description

@jjangga0214

Feature hasn't been suggested before

  • 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:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "doom_loop": {
      "4": "ask",
      "6": "deny"
    }
  }
}

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.

Activity

added
coreAnything pertaining to core functionality of the application (opencode server stuff)
on Apr 20, 2026
assigned and unassigned on Apr 26, 2026
removed
coreAnything pertaining to core functionality of the application (opencode server stuff)
on May 3, 2026

Keesan12 commented on Jun 5, 2026

@Keesan12

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.

github-actions commented on Aug 5, 2026

@github-actions
Contributor

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions