doom_loop never fires when repeated calls span steps: check only reads the current assistant message #51965

Activity

1. github-actions

   assigned

   jlongster

   on Sep 29, 2026
2. github-actions commented on Sep 29, 2026

   

   github-actionsBot

   on Sep 29, 2026 – with GitHub Actions

   Contributor

   More actions

   ---

   This issue may overlap with existing reports of doom_loop detection gaps. Please check:

   • bug(processor): doom loop detection misses cross-message repetitions and has inverted filter order #25254: Same cross-message/current-assistant-message scope bug in processor.ts; it was closed for inactivity, and its comments include reports that the bug is still present.
   • Doom-loop detection misses periodic tool-call cycles #47759: Related detector gap for periodic tool-call cycles, though that reproduction occurs within one processor step.
   • subagent: infinite loop of identical tool calls for ~50min with no loop protection, uncontrollable token burn #45442: Related report of repeated identical tool calls without loop protection in a subagent.
3. calebtt commented on Sep 29, 2026

   

   calebtt

   on Sep 29, 2026

   Author

   More actions

   Thanks. I checked all three before filing, and they're linked in the description.

   • bug(processor): doom loop detection misses cross-message repetitions and has inverted filter order #25254 is the same bug. The stale bot closed it and asked for a new issue if it was still relevant, so this is that issue. The check around line 353 of processor.ts is unchanged in v1.18.33 and on dev. PR fix(processor): detect doom loops across messages instead of within current message #32089 fixes it and is still open.
   • 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.
   • subagent: infinite loop of identical tool calls for ~50min with no loop protection, uncontrollable token burn #45442 shows the same symptom from a subagent: 364 consecutive messages with identical tool input. That thread looks at permission settings and subagent permission schemes rather than where the check looks. This scope bug would explain it, because its repeated calls were also spread across separate messages.

   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.
4. gauntface commented on Oct 7, 2026

   

   gauntface

   on Oct 7, 2026

   More actions

   Just encountered this as well with same root cause. I believe the MessageV2.filterCompactedEffect(ctx.sessionID) change from #32089 would fix the immediate issue.
5. lvjing2 commented on Oct 17, 2026

   

   lvjing2

   on Oct 17, 2026

   More actions

   I checked V2 dev 8c173a8f3805d8e749d44311054b07e37a1b2ce1. I couldn't find a cross-step repeat check in the runner; doom_loop still appears in the V1 config compatibility code. The runner has an optional steps limit, but that doesn't distinguish repetition from useful work.

   I ran a scripted reproduction on 22e771f5893e255ea78fc10557ed3fb98d3a1072; the relevant runner files are unchanged in the newer commit. Eight identical failed tool calls across eight steps all execute, followed by a ninth model request to stop. There are no provider retry events. With steps=5, only four tool bodies execute. This proves the harness behavior, not how often real models get stuck.

   Would a V2 follow-up here make sense, starting with consecutive identical calls across steps? I'd keep the history bounded and cover user input, intervening work and successful polling so legitimate retries aren't blocked. Changed-input failure feedback and periodic cycles could stay out of that first change.

   Minimal reproduction in the existing runner test file

   Add this scenario inside the existing SessionRunnerLLM describe block in packages/core/test/session-runner.test.ts:

   scenario("tool failure feedback repro: eight failed steps", function* (s) {
       const registry = yield* Tool.Service
       const calls: string[] = []
       yield* transformTools(registry, {
         lookup: {
           name: "lookup",
           description: "Look up a missing fixture resource",
           input: Schema.Struct({ resource: Schema.String }),
           output: Schema.Struct({}),
           execute: ({ resource }) => {
             calls.push(resource)
             return new Tool.Error({ message: "Resource not found" })
           },
         },
       }, { codemode: false })
       yield* s.admit("Look up the missing resource")
       yield* s.llm.push(
         ...Array.from({ length: 8 }, (_, index) =>
           TestLLM.tool(`lookup-${index}`, "lookup", { resource: "missing" }),
         ),
         TestLLM.stop(),
       )
       yield* s.resume
       expect(calls).toEqual(Array(8).fill("missing"))
       expect(s.requests).toHaveLength(9)
       const events = yield* recordedEventTypes(sessionID)
       expect(events.filter((type) => type === "session.tool.failed.2")).toHaveLength(8)
       expect(events).not.toContain("session.retry.scheduled.1")
     })

   From packages/core, using Bun 1.4.2:

   bun run script/test.ts test/session-runner.test.ts --test-name-pattern 'tool failure feedback repro'

   The minimal reproduction passes. The broader local baseline has six cases, all passing across ten repetitions; the full runner file and Core typecheck also pass. No runtime behavior has been changed.
6. opencode-agent commented on Oct 19, 2026

   

   opencode-agentBot

   on Oct 19, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. This is against the V1 session processor, and the doom_loop check was removed in V2. Since V1 won't get a fix for this, we're closing it. Please update to the latest OpenCode release, and if you still see repeated tool-call loops there, open a new issue with your V2 version and repro steps.
7. opencode-agent

   closed this as not plannedon Oct 19, 2026