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

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: #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.

No source file or test is named in the report. Start by tracing the official harness's handling of repeated identical Read calls and inspect the session wire.jsonl if it is provided; compare the observed behavior with the existing reminder logic. Done means an identical-call loop is reliably stopped or otherwise prevented from continuing, with regression coverage for the reported Read-to-Edit scenario.