Skip to content

[Bug] Agent stuck in repeated Read-tool loop, unable to emit intended Edit calls #2637

Description

@devalirzayev

What version of Kimi CLI is running?

0.41.0

Which open platform/subscription were you using?

Kimi Code CLI with its official harness (not Claude Code / opencode / any third-party harness)

Which model were you using?

Default model of the Kimi Code CLI session (exact model name not visible to me in-session)

What platform is your computer?

macOS (bash)

What issue are you seeing?

During a git merge-conflict resolution task (2 conflicted files), the agent correctly read the conflicted regions, then entered a loop in which it emitted the same Read tool calls 20+ times in a row instead of the Edit calls it planned. Details that make this a distinct data point:

  • Intent/emission mismatch: in nearly every looping turn the reasoning text explicitly stated "now I will emit Edit calls" — but the emitted tool call was Read again, with the exact same parameters.
  • Reminders didn't help: the loop persisted through the harness's repeated-call system reminders ("The same tool call has been repeated several times in a row", including the forced 3-option variant) — the model acknowledged them and then re-emitted the same Read.
  • User commands didn't help: direct user instructions ("apply changes. don't tool loop.") did not break the loop either.
  • Cross-topic leakage: after the user pivoted to unrelated questions, stray Read calls of the same two file regions kept appearing at the start of turns, interleaved with other (successful) tool calls like Bash.
  • Other tools worked: Bash and other tools executed normally when emitted — the loop specifically re-emitted Read of the previously-read regions.
  • No compaction: no auto-compaction had occurred in this session (possibly related: Kimi CLI stuck in reading one file again and again and stuck in a loop #640, where the reporter suspected compaction).
  • The loop only paused when the user interrupted/ended turns; the underlying tendency remained and resurfaced several messages later.

What steps can reproduce the bug?

Not reliably reproducible on demand. Trigger context: merge-conflict resolution where the agent read the same conflict regions repeatedly (following the Edit-tool guidance to re-read before consecutive same-file edits), then got stuck re-issuing those exact Read calls.

What is the expected behavior?

After reading files, the agent emits the planned Edit calls. And if the model does degenerate into repeating an identical tool call, the harness should hard-stop the turn after N identical consecutive calls — the current loop-detection reminder is advisory only and was ignored by the model.

Additional information

Possibly the same root cause as #640. This report adds: official-harness occurrence, an explicit intent-vs-emission mismatch, and failure of both system reminders and direct user commands to break the loop. I can provide the session wire log (wire.jsonl) if useful — let me know and I'll attach it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions