Agent loops on same shell command; output truncated

[yangliping]

What version of Kimi Code CLI is running?

kimi, version 1.40.0

Which open platform/subscription were you using?

Kimi Code

Which model were you using?

kimi-for-coding

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

I’m encountering two related issues recently:

1. Apparent infinite loop with repeated shell commands
   When the agent is analyzing a codebase and searching for symbols (e.g., class Decompress... or def get_visible), it repeatedly issues the exact same grep command dozens of times. Even after the command has already returned results, the agent continues to execute identical queries in a loop until I manually interrupt it with Ctrl+C.
   Screenshot evidence: the same grep -n "class Decompress ... press_submission.py -A 10 was executed ~15 times consecutively, and later grep -n "def get_visible" ... s/task/auto_sync.py -A 25 was executed another ~12 times. I had to interrupt twice with “你是不是死循环了？”.

2. Command/response content truncated
   Starting from a recent version, the CLI no longer displays the full content of commands or their outputs. Long paths and arguments are collapsed into ... (e.g., grep -n "class Decompress ... press_submission.py -A 10), making it impossible to see exactly which file is being queried or what the full output was. This significantly hinders debugging when the agent misbehaves.

What steps can reproduce the bug?

1. Open a mid-to-large Python project in kimi-cli.
2. Ask the agent to analyze or locate a specific class/function (e.g., “find where DecompressSubmission is defined” or “explain get_visible in auto_sync.py”).
3. The agent starts spawning grep commands via Used Shell (...).
4. Observe: the agent repeats the same grep command many times instead of stopping after the first successful result.
5. Observe: the command string itself is truncated with ... in the terminal UI, so the full path/arguments are hidden.

What is the expected behavior?

• Deduplication / loop prevention: After a grep or ReadFile call returns valid data, the agent should use that information to proceed with the task, rather than re-issuing the identical command indefinitely.
• Full content display: The CLI should show the complete command string and its full output (or at least provide a --verbose/debug flag to do so), as it did in earlier versions.

Additional information

• The issue happens intermittently but has become frequent recently.
• I have already tried interrupting the session (Interrupted by user), but the agent resumes the same loop when a similar query context is given.
• Screenshots attached showing the repeated Used Shell entries and the truncation with ....

[loresun]

Confirming this is still present on kimi, version 1.44.0 (latest as of 2026-05-22).
The loop count went much higher in our case — we drive kimi non-interactively from
a scheduler, so there is no human to Ctrl+C, and the agent keeps repeating the same
tool call until our outer process kills the subprocess at the 7200s timeout.

Two reproducible cases from the last 24h (full session jsonl available locally):

Case A — successful first call, still repeats 76×

• Task: a research agent asked to look up recent playwright + mcp GitHub repos.
• Command issued: curl -s 'https://api.github.com/search/repositories?q=playwright+mcp+created:>2026-05-01&sort=stars&order=desc&per_page=20' | python3 -c "..."
• Call feat: add /setup meta command #1 returned full, correct data (4,653 bytes, 20 repos with names/urls/stars).
• Calls feat: auto updating in background #2 through feat: add Alt+Enter for multi-line input #75: byte-identical command, byte-identical successful result.
• Call feat: handle race condition in file rotation using atomic file creation with retry mechanism #76: kimi-cli started attaching a <system-reminder>You are repeating the exact same tool call with identical parameters. Please carefully analyze the previous result. If the task is not yet complete, try a different method or parameters instead of repeating the same call.</system-reminder> to the tool return.
• The model ignored the reminder and would have kept going — our scheduler killed the subprocess at 7,198 s after 697 `StepBegin` events in `wire.jsonl`.

Case B — empty result from over-filtered grep, still repeats 112×

• Task: list prompts from a local API while filtering out a long block-list (`curl … | grep -v | grep -v … | grep -v `).
• Every call returned empty (the grep chain filtered out everything).
• 112 identical calls, all empty, all carrying the same system-reminder.

Observed behavior summary

1. The `` injected by kimi-cli into the tool return appears to have no behavioral effect — at least not for `kimi-for-coding` / `kimi-latest` models used here.
2. There is no per-session hard cap on identical-arguments repeats, so headless / scheduler-driven deployments will burn the full subprocess timeout (and a lot of tokens) on every occurrence.
3. The trigger is not "first call failed" — Case A above proves it loops even when the first call clearly succeeded.

What would help us (and probably others running kimi non-interactively)

• A configurable hard-cap on consecutive identical tool calls (e.g., `--max-repeated-tool-calls 5`), which `abort`s the session with a structured error rather than relying on the model to obey the reminder.
• Exposing the repeat count in the JSON status stream (`StatusUpdate.payload`) so outer schedulers can SIGTERM proactively without parsing the full `context.jsonl`.

Happy to share the raw `context.jsonl` / `wire.jsonl` privately if it helps.

Environment: kimi 1.44.0, model = `kimi-for-coding` (via `kimi-code/kimi-for-coding`), Darwin 25.2.0 arm64.

---

（中文补充）
我们在调度系统里跑 kimi 触发了同样的 bug，且因为没有人按 Ctrl+C，每次循环都会一直跑到 7200s 超时被外部进程杀掉。证据：

• Case A：第 1 次 `curl` 调用就成功返回 4.6KB 的完整 GitHub 仓库列表，但 agent 仍然把同一条命令重复了 76 次，jsonl 里能看到 697 个 step。
• Case B：grep -v 链把输出全过滤掉了，agent 把空结果的同一条命令重复 112 次。

两个 session 的 tool return 里都注入了 kimi-cli 自带的 `You are repeating the exact same tool call...`，但模型完全没听。建议在 cli 侧加一个 hard cap（比如 `--max-repeated-tool-calls 5`）直接 abort，不要依赖模型自觉。