Doom loop is not caught when during reasoning or output #12716

This issue might be a duplicate of existing issues. Please check:

• Infinite retry loop when StreamIdleTimeoutError occurs during tool input generation #12234: Infinite retry loop when StreamIdleTimeoutError occurs during tool input generation
• Tasks/Subagents with Codex / OpenAI are frequently getting stuck with no timeout/retry, which then hangs the session forever #11865: Tasks/Subagents with Codex frequently getting stuck with no timeout/retry
• always stuck at “Preparing write...” #11112: Agent stuck at 'Preparing write...' in a tool execution loop
• Loop in certain models #3743: Loop in certain models (explicitly mentions 2-8B models like yours)
• Has anyone been successful at setting up Kimi K2.5 via NanoGPT? #11529: Kimi K2.5 loops over in reasoning with smaller models

Feel free to ignore if none of these address your specific case.

doom_loop — triggered when the same tool call repeats 3 times with identical input

(ref) I don't see any tool calls in your screenshot.

Yeah. That's what I mean. It makes sense for it to catch non-tool call doom loops.

Oh I see, you are targeting this as a feature request. Ok cool, but please mark the issue as such (e.g. using [FEATURE] tag in the title), the feature works as currently designed and is not a bug.

same problem

doom loop in thinking has been especially strange because it will think forever, like longer than the context window usually allows. does opencode just continually send requests in thinking mode?

the doom_loop: deny switch is not working, using opencode github plugin, we are seeing several doom loops in PR reviews.

| Read {"filePath":"<CI_WORKSPACE>//verif/tbs/xbar/agents/xbar_mport_scheduler/xbar_mport_scheduler.sv","limit":25,"offset":127}

| Read {"filePath":"<CI_WORKSPACE>//verif/tbs/xbar/agents/xbar_mport_scheduler/xbar_mport_scheduler.sv","limit":25,"offset":127}

| Read {"filePath":"<CI_WORKSPACE>//verif/tbs/xbar/agents/xbar_mport_scheduler/xbar_mport_scheduler.sv","limit":25,"offset":127}

| Read {"filePath":"<CI_WORKSPACE>//verif/tbs/xbar/agents/xbar_mport_scheduler/xbar_mport_scheduler.sv","limit":25,"offset":127}

Also see patterns like A B A B A B A B also not get detected.

Ultimately filled up context limit since it cannot be interactively stopped on github opencode plugin

I’d treat this as a separate detector rather than extending tool doom-loop logic.

For reasoning/output loops, the primitive is repeated assistant turns with near-identical content and no external state change, plus a hard cap on consecutive model-only turns. Otherwise smaller models can burn tokens forever without ever touching the tool layer, which means the existing guard never even gets a chance to help.

Related: opened PR #32089 which fixes the doom loop detection for tool calls across messages. The reasoning/output loop detection you describe here is a separate issue that would need its own fix (detecting repetitive text/reasoning blocks, not tool calls). PR #21112 appears to be working on that.

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