Doom loop is not caught when during reasoning or output

[Heinrich-XIAO]

Description

This is never caught.

Plugins

None

OpenCode version

1.1.53

Steps to reproduce

1. Ask an agent to think about a certain word 100 times. Preferrably, a smaller model like 2-8B

Screenshot and/or share link

Operating System

m1 mac air tahoe 26.3

Terminal

Mac Default Terminal

[github-actions]

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.

[Nindaleth]

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.

[Heinrich-XIAO]

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

[Nindaleth]

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.

[zenoda]

same problem

[dezren39]

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?

[sandeep-chaps]

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

[Keesan12]

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.

[JustSidus]

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.

[github-actions]

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