fix(session): detect periodic tool-call cycles

[yixiao5428]

Issue for this PR

Closes #47759

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

The current guard catches A,A,A but misses cycles such as A,B,A,B,A,B. This change detects three consecutive repetitions of an ordered tool-call block of length 1–10 within one processor, using the existing doom_loop permission flow.

Related approaches:

• fix: stop repeated identical tool call loops #46272 adds a stop after ten consecutive identical calls. This PR also detects multi-call cycles and preserves permission-based continuation rather than adding an unconditional stop.
• fix(processor): detect doom loops across messages instead of within current message #32089 counts matching tool/input occurrences across uncompacted history. That can also catch alternating calls, but does not require repeated blocks. This PR checks an ordered suffix without scanning persisted history.

Key properties:

• Bounded detector history: 21 signature slots and capped per-period counters. Consecutive matching triples establish equality of all three blocks; retained bytes still depend on input size.
• Each active call contributes once, including when metadata starts execution early or concurrent updates replace its record. A shared admission cell prevents stale updates from resetting this state.
• Existing JSON input comparison and permission payloads are preserved; no provider, public schema, or dependency changes.

How did you verify your code works?

Validated the exact contribution in a fresh frozen-lockfile installation with Bun 1.3.14:

bun test --cwd packages/opencode --timeout 30000 test/session test/permission test/provider/transform.test.ts
bun run --cwd packages/opencode typecheck
bun run typecheck

Results: 1,116 passed, 0 failed, 7 skipped, 1 todo; package typecheck passed; workspace typecheck 30/30 passed with no cache hits. Tests cover an independent suffix-block oracle, exact trigger boundaries, duplicate delivery, metadata races, history isolation, and permission outcomes. The periodic-cycle and metadata regressions were demonstrated failing before their corresponding fixes.

Screenshots / recordings

Not applicable; no UI changes.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

🤖 Generated with Claude Code

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Related PRs Found

The search identified two related PRs that address similar cycle/loop detection concerns:

1. PR fix: stop repeated identical tool call loops #46272 - fix: stop repeated identical tool call loops

   • Addresses consecutive identical tool calls (A,A,A pattern)
   • This PR improves upon it by also detecting multi-call cycles (A,B,A,B patterns)

2. PR fix(processor): detect doom loops across messages instead of within current message #32089 - fix(processor): detect doom loops across messages instead of within current message

   • Detects matching tool/input occurrences across history
   • This PR differs by checking ordered suffixes without scanning persisted history

Important Note: The current PR (47797) is explicitly designed to complement rather than duplicate these PRs:

• It preserves permission-based continuation (unlike fix: stop repeated identical tool call loops #46272's unconditional stop)
• It checks bounded suffix blocks efficiently (unlike fix(processor): detect doom loops across messages instead of within current message #32089's history scanning approach)
• It handles both single and multi-call repeating patterns

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.