fix(cli): auto-continue max iterations in --yolo mode#1737
fix(cli): auto-continue max iterations in --yolo mode#1737frntn wants to merge 4 commits intodocker:mainfrom
Conversation
When running in non-interactive mode with --yolo (e.g. `cagent exec --yolo`), reaching max_iterations triggers a stdin prompt that fails immediately with "Failed to read input, exiting..." since stdin is piped or closed. This fix proposal makes --yolo consistent: it now auto-approves iteration extensions just like it auto-approves tool calls. A safety cap of 5 extensions (+50 iterations) prevents infinite loops. TL;DR : in --yolo mode, cagent now auto-approve the "max-iterations" continuation (up to 5 times) instead of prompting stdin (which fails immediately in non-interactive/piped contexts) Signed-off-by: Matthieu FRONTON <m@tthieu.fr>
The JSON event loop (`--json`) did not handle MaxIterationsReachedEvent at all, causing the runtime to hang on resumeChan indefinitely. Apply the same auto-continue logic as the normal output path: auto-approve in --yolo mode (with safety cap), reject otherwise. Signed-off-by: Matthieu FRONTON <m@tthieu.fr>
Cover --yolo auto-continue behavior for MaxIterationsReachedEvent in both normal and JSON output modes, including safety cap enforcement. Signed-off-by: Matthieu FRONTON <m@tthieu.fr>
Deduplicate MaxIterationsReachedEvent logic between JSON and normal output modes into a single helper with a ternary return type (continue/stop/prompt). Signed-off-by: Matthieu FRONTON <m@tthieu.fr>
|
I'm not really sure of this.. The max iterations feature was designed exactly for this purpose, to not iterate forever. Auto approving that confirmation prompt silently when using IMHO a better approach is just to set |
|
Thanks for the review @krissetto I had the same initial thought, but while running benchmarks on multiple coding agents using harbor framework (including cagent, which turns out to be one of my fav) I realized two things :
Bonus: This PR also fixes the JSON output mode, which was completely missing handling for MaxIterationsReachedEvent and caused a runtime hang. Does that make more sense to you? |
|
@frntn I do agree it could be nice, just not totally sure its the right move. If we go with it, we need to document the behavior properly too both in the --yolo and --max-iteration sections to make it very clear to users. Agree we need to handle the To be clear, I'm not strongly against the change. Let me stew on it just a bit and get back to you |
|
Maybe using a proper wording in the description like "soft-limit" and "hard-limit" can help |
2 participants
Problem
When running
cagent exec --yoloin non-interactive mode (stdin closed/piped),hitting the max iterations limit triggers a stdin prompt that immediately fails
with "Failed to read input, exiting...".
This is inconsistent:
--yoloauto-approves tool calls but not iteration extensions.Fix
--yolomode (capped at 5 to prevent infinite loops)MaxIterationsReachedEventin JSON output mode (was completely missing, causing runtime hang)handleMaxIterationsAutoApprovehelper to avoid duplication between normal and JSON pathsTest plan
golangci-lint run ./pkg/cli/...→ 0 issuesgo test ./pkg/cli/...→ 16/16 PASS