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
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.
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.
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
Readtool calls 20+ times in a row instead of theEditcalls it planned. Details that make this a distinct data point:Readagain, with the exact same parameters.Read.Readcalls of the same two file regions kept appearing at the start of turns, interleaved with other (successful) tool calls likeBash.Bashand other tools executed normally when emitted — the loop specifically re-emittedReadof the previously-read regions.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
Readcalls.What is the expected behavior?
After reading files, the agent emits the planned
Editcalls. 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.