DEV Community

Ramdai Bista
Ramdai Bista

Posted on Originally published at stupidllm.com

Cline's Loop Detector Aborted a Run Over a Bug Its Own Maintainer Couldn't Reproduce

A Cline user running a fully local stack — Cline 3.0.68, Windows 11, llama.cpp serving Qwen3.6-35B-A3B through the openai-compatible provider — hit a run_commands tool call that came back empty or truncated. Cline's own safety net caught it, then aborted the run with a message that pointed at the wrong cause.

What the source says

cline/cline#14827, filed October 4, 2026 by anachaudhari, describes run_commands arriving as {"commands":[]} or as an unparseable fragment like {"commands":[":\""]}, while other tool calls (editor) in the same session came through intact. In the worst run this happened seven times straight — two empty calls, five identical fragments — until Cline's loop detector fired ("Detected 5 consecutive identical calls to run_commands; stopping to avoid a loop"), the yolo-mode three-strikes limit was hit, and the run died with run_aborted / external_abort and the message "aborted by another client" — even though no other client was involved. A second run also started with an empty call but recovered and finished normally.

The reporter instrumented a logging proxy: 16 requests, 2,333 streamed tool-call argument deltas, every one reassembling into valid JSON. The corruption never showed up in transit, and it didn't reproduce at all in the 3 proxied runs, versus 3 of 4 direct runs.

Maintainer mkondratek responded October 7: no chunk-boundary bug on Cline's side, but llama.cpp returning finish_reason: "length" (hitting the output-token limit) can route through a repair step that turns a cut-off call into an empty command list. PR #14909 would stop a cut-off call from executing instead of running on partial arguments — but it's parked, not merged. After requests for the specific failing request's finish_reason and llama-server slot diagnostics went unanswered, the maintainer reviewed roughly 2 million production responses over two weeks and, on October 19, found 372 that hit the output limit — none of them mid-tool-call, none with an empty command list. Conclusion: probably specific to this reporter's local setup, not a general Cline defect. A second PR, #15089, aims to turn a bare empty command list into a visible error instead of a silent one.

What it doesn't establish

This is not a confirmed Cline bug with a known root cause. The maintainer's own large-scale review found nothing matching the reported shape and leans toward the problem being specific to this local openai-compatible/llama.cpp path. No data was lost and no command executed on truncated arguments — the loop detector did exactly what it's supposed to do. The cost here is a wasted run and a misleading abort message, not a safety failure.

Why it's still worth logging

The interesting part isn't the truncation — it's the error message. "Aborted by another client" is actively wrong; nothing else touched the session. When a safety mechanism (the loop detector) correctly stops a bad pattern but reports a cause that didn't happen, it costs the next person debugging this far more time than the original bug would have, because they go looking for a phantom second client. PR #15089's fix — make the empty-list case loud instead of silent — is aimed at exactly that gap, and it's still open.

Full record, severity rationale, and frontmatter: https://www.stupidllm.com/incident/STUPID-2026-0144/

Top comments (0)