fix(cli): auto-continue max iterations in --yolo mode

[frntn]

Problem

When running cagent exec --yolo in 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: --yolo auto-approves tool calls but not iteration extensions.

Fix

• Auto-approve iteration extensions in --yolo mode (capped at 5 to prevent infinite loops)
• Handle MaxIterationsReachedEvent in JSON output mode (was completely missing, causing runtime hang)
• Extract shared logic into handleMaxIterationsAutoApprove helper to avoid duplication between normal and JSON paths

Test plan

• 5 new tests covering: yolo auto-approve, safety cap, JSON mode, reject without yolo, JSON safety cap
• golangci-lint run ./pkg/cli/... → 0 issues
• go test ./pkg/cli/... → 16/16 PASS

[krissetto]

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 --yolo could lead to unexpected (and potentially very expensive) consequences for the user.

IMHO a better approach is just to set --max-iterations 999 or some other very high value, so at least what's happening is explicitly chosen by the user. WDYT?

[frntn]

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 :

1. bumping max-iterations is workaround, the bug remains that if the agent reaches that limit in non-interactive mode, the runtime tries to prompt a user that doesn't exist and crashes
2. It's a consistency fix for yolo semantics which already auto-approves tool calls. I opted for full auto-approve, but one specific prompt still requires manual input (and breaks when there's no interactive terminal). That's not a safety net but a bug as I cannot reply "yes". The fix aligns the behavior with yolo semantic which means "auto-approve everything". A safety cap still prevents runaways

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?
It's really a practical fix from what I experienced and expected, not some theoretical one :)

[krissetto]

@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 exec command better in non-interactive scenarios though.

To be clear, I'm not strongly against the change. Let me stew on it just a bit and get back to you

[frntn]

Maybe using a proper wording in the description like "soft-limit" and "hard-limit" can help

[krissetto]

agree with the wording

[krissetto]

/review

[docker-agent]

Review Summary

⚠️ Found 2 HIGH severity bugs that need to be fixed:

1. autoExtensions counter resets on every message - The safety cap of 5 auto-extensions can be bypassed in multi-turn conversations
2. Missing Resume call in JSON mode - When AutoApprove is true for ToolCallConfirmationEvent, no Resume is sent, causing the runtime to hang

One additional MEDIUM severity issue about silent rejection in JSON mode.

All issues are in the newly added code.

[docker-agent]

🔴 HIGH SEVERITY: Safety cap can be bypassed in multi-turn mode

The autoExtensions counter is declared inside oneLoop(), which gets reset to 0 on every call. This defeats the purpose of the safety cap:

• In multi-turn mode (line 280-281), oneLoop() is called once per message
• Each call gets a fresh counter starting at 0
• If a user provides 10 messages, each can use up to 5 auto-extensions = 50 total extensions instead of 5

Fix: Move autoExtensions := 0 outside of oneLoop() to the Run() function level, so the counter persists across all messages in the session:

func Run(ctx context.Context, out *Printer, cfg Config, rt runtime.Runtime, sess *session.Session, userMessages []string) error {
    // ... existing code ...
    var lastErr error
    autoExtensions := 0  // <-- Move here
    
    oneLoop := func(text string, rd io.Reader) error {
        // Remove: autoExtensions := 0
        // ... rest of function ...
    }
}

This ensures the safety cap applies to the entire session, not per-message.

[docker-agent]

🔴 HIGH SEVERITY: Missing Resume call causes runtime to hang

When cfg.AutoApprove is true in JSON mode, this code does not call rt.Resume() at all. This leaves the runtime waiting indefinitely for a confirmation that never comes.

The current logic:

• If !cfg.AutoApprove: calls rt.Resume(ctx, runtime.ResumeReject(""))
• If cfg.AutoApprove: does nothing ❌

Fix: Add an else branch to approve when AutoApprove is enabled:

case *runtime.ToolCallConfirmationEvent:
    if !cfg.AutoApprove {
        rt.Resume(ctx, runtime.ResumeReject(""))
    } else {
        rt.Resume(ctx, runtime.ResumeApprove())  // <-- Add this
    }

This mirrors the MaxIterationsReachedEvent handling pattern on lines 112-119 and ensures consistency with non-JSON mode (lines 152-167).

[docker-agent]

⚠️ MEDIUM SEVERITY: Silent rejection without user feedback

When not in yolo mode or when the safety cap is reached, this code rejects and returns with no visible indication to the user consuming the JSON output.

The problem:

• User sees MaxIterationsReachedEvent in JSON output
• Runtime calls rt.Resume(ctx, runtime.ResumeReject("")) silently
• Process terminates with no event showing what action was taken
• Resume actions are sent through an internal channel, not emitted as events

Impact: JSON API consumers cannot determine why execution stopped or what decision was made. The comment acknowledges "no interactive prompt in JSON mode" but doesn't address the lack of visibility.

Consider: Emitting a custom event before rejecting to inform JSON consumers of the decision, similar to how interactive mode shows clear feedback.