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
doom_loop never fires when repeated calls span steps: check only reads the current assistant message #51965
Each step is its own assistant message. When the model makes one tool call per step, that message holds [step-start, tool] at the time of the check, so recentParts.length is 2 and the check returns early. The guard cannot fire however many times a call repeats across steps. It only catches three identical calls inside a single response.
This was reported in #25254, which the stale bot closed with a request to open a new issue if it was still relevant. It is still present in v1.18.33 and on dev. PR #32089 changes the check to count matching tool parts across the session and has been open since June. #45442 looks like the same cause, seen from a subagent.
What we saw. v1.18.33, local model through @ai-sdk/openai-compatible. In an 83-step session, every assistant message had exactly three parts: step-start, one tool, step-finish. From step 13 on, the model alternated between two bash calls about 70 times over roughly 10 minutes, until it was cancelled. Two user messages sent during the loop, one pointing it out and one redirecting the task, did not change the next call. The log has no doom_loop evaluation for the session. An earlier session on v1.18.32 alternated between two commands for 183 calls in the same way.
The alternation is also the pattern in #47759, but the scope problem hides it first: even a single command repeated once per step is never seen.
Plugins
None
OpenCode version
1.18.33 (also seen on 1.18.32)
Steps to reproduce
Leave doom_loop at its default (ask).
Use a model that makes one tool call per response, e.g. a local model through @ai-sdk/openai-compatible.
Get it to issue the same bash call with identical input in three or more consecutive steps.
No doom_loop prompt appears. In the session DB, each step's assistant message has parts [step-start, tool, step-finish].
Doom-loop detection misses periodic tool-call cycles #47759 covers periodic cycles within a single step. Our loop was also period-2, and I added our details there. Detecting periods alone would not have caught our case: with one tool call per step, the current check never sees more than one call.
This issue covers only the scope of the check, and that gap blocks the other two. Once the check spans the calls since the last user message, it catches repeats like #45442's, and period detection for #47759 can build on it.
Just encountered this as well with same root cause. I believe the MessageV2.filterCompactedEffect(ctx.sessionID) change from #32089 would fix the immediate issue.
Activity
github-actions commentedon Sep 29, 2026
This issue may overlap with existing reports of
doom_loopdetection gaps. Please check:processor.ts; it was closed for inactivity, and its comments include reports that the bug is still present.calebtt commentedon Sep 29, 2026
Thanks. I checked all three before filing, and they're linked in the description.
processor.tsis unchanged in v1.18.33 and ondev. PR fix(processor): detect doom loops across messages instead of within current message #32089 fixes it and is still open.This issue covers only the scope of the check, and that gap blocks the other two. Once the check spans the calls since the last user message, it catches repeats like #45442's, and period detection for #47759 can build on it.
gauntface commentedon Oct 7, 2026
Just encountered this as well with same root cause. I believe the
MessageV2.filterCompactedEffect(ctx.sessionID)change from #32089 would fix the immediate issue.