fix(kiro_cli): honor --yolo and profile.model at launch

[haofeif]

fix(kiro_cli): honor --yolo and profile.model at launch

Summary

Three issues with the kiro_cli provider are fixed here, plus a follow-on doc fix for opencode_cli after it merged into this branch:

1. cao launch --yolo did not bypass Kiro CLI's permission prompts. CAO sets allowed_tools=['*'] for yolo, but the kiro_cli provider never translated that into kiro-cli chat --trust-all-tools. Every tool invocation re-prompted, which blocks assign/handoff flows inside multi-agent workflows.
2. profile.model was ignored. The agent-profile model: frontmatter field was never passed to kiro-cli, so workflows pinning model: claude-opus-4.6 (or similar) silently ran on kiro-cli's default (auto).
3. kiro-cli 2.0.1's new TUI blocks yolo launches with a consent dialog. Starting in kiro-cli 2.0.0, the new TUI shows an interactive "Kiro is running in trust all tools mode / Yes, I accept" dialog before the chat becomes ready when launched with --trust-all-tools. CAO cannot answer it headlessly, so initialization hangs until timeout → 500 to the caller.
4. cao launch --yolo was silently ignored on opencode_cli. After PR feat: Add OpenCode CLI provider support #193 merged into main and into this branch, the new opencode_cli provider inherited the same gap as kiro_cli had — but unlike kiro, opencode's TUI has no upstream runtime flag to translate --yolo into (tracked at [FEATURE]: Add --dangerously-skip-permissions (aka YOLO mode) anomalyco/opencode#8463). So this PR documents the limitation and adds a launch-time warning rather than a code fix.

Kiro flags are now honored, yolo launches on kiro skip the TUI entirely in favor of --legacy-ui to avoid the consent dialog, and opencode users get a clear runtime warning pointing them at the install-time workflow.

Background

PR #189 ("honor profile.model at terminal creation") fixed the --model gap for claude_code / codex / gemini_cli / kimi_cli / copilot_cli, but the PR body assumed kiro_cli already baked model selection in at install time:

That assumption is incorrect. The kiro_cli provider's initialize() built the command as kiro-cli chat --agent {profile} with no --model flag and no read of profile.model. Install-time baking does not cover runtime model overrides, so the field was effectively dead.

The yolo gap is separate — it has been there since the provider was introduced. Other providers handle their equivalent flag (--dangerously-skip-permissions, --yolo, etc.) unconditionally; kiro_cli did not.

The consent-dialog issue is a kiro-cli 2.0 regression (kirodotdev/Kiro#7398, aws/amazon-q-developer-cli#3751). Confirmed on kiro-cli 2.0.1: the new TUI still shows the dialog; only --legacy-ui, --classic, and --no-interactive bypass it. CAO drives kiro-cli through a TUI inside tmux, so --legacy-ui is the only viable path when --trust-all-tools is set.

Matrix (verified locally on kiro-cli 2.0.1):

UI mode	Consent dialog	Works headless?
--tui (default)	Shown, blocks	❌
--classic	Not shown	✅
--legacy-ui	Not shown	✅
--no-interactive	Not shown	✅

Changes

src/cli_agent_orchestrator/providers/kiro_cli.py:

• Add _get_profile_model() helper: best-effort profile load, returns profile.model if available, None otherwise. Missing profile is not fatal — kiro-cli has its own agent store, so a profile that isn't CAO-registered must not block launch.
• In initialize(), when self._allowed_tools contains "*" (yolo):
  • Launch directly with kiro-cli chat --legacy-ui --trust-all-tools [--model <m>] --agent <profile>. The TUI attempt is skipped entirely because its consent dialog cannot be dismissed headlessly.
  • On timeout, raise immediately — no second fallback. This prevents the prior ~30-second double-timeout (TUI 30s → legacy 30s) that surfaced as a 500 to the caller.
  • Log INFO: "kiro_cli yolo mode: forcing --legacy-ui (kiro-cli 2.0.1 TUI shows a non-bypassable trust-all-tools consent dialog)".
• In initialize(), when not yolo:
  • Preserve the existing TUI-first behavior with --legacy-ui fallback on timeout.
  • --model is forwarded on both the TUI attempt and the legacy fallback.

test/providers/test_kiro_cli_unit.py:

• Existing tests now patch load_agent_profile (it's called on every initialize() now). Original assertions preserved verbatim.
• New / updated tests (5):
  • test_initialize_yolo_forces_legacy_ui_with_trust_all_tools: yolo launches with --legacy-ui --trust-all-tools on the first command — no TUI attempt.
  • test_initialize_passes_profile_model: profile.model → command contains --model <value>.
  • test_initialize_yolo_and_model_combine: both yolo flags and --model appear together in the expected order (on the single legacy-ui launch).
  • test_initialize_yolo_no_fallback_on_timeout: yolo timeout raises without a second launch attempt.
  • test_initialize_non_yolo_legacy_ui_fallback_preserves_model: non-yolo TUI timeout falls back to --legacy-ui, and the --model flag is preserved on both attempts.

src/cli_agent_orchestrator/cli/commands/launch.py (opencode_cli follow-on):

• When --yolo is set and provider == "opencode_cli", emit a yellow warning explaining that --yolo has no runtime effect on opencode_cli and pointing users at cao install with allowedTools: ["*"].
• Rationale: opencode's TUI has no equivalent to --dangerously-skip-permissions / --trust-all-tools / --yolo. The flag exists only on opencode run (the headless one-shot command) which CAO does not drive. Tracked upstream in [FEATURE]: Add --dangerously-skip-permissions (aka YOLO mode) anomalyco/opencode#8463 and siblings, all still open.

docs/opencode-cli.md (opencode_cli follow-on):

• Fixed the inaccurate "pass --yolo to allow all 13 tools" note (it implied runtime widening, which doesn't work).
• Added a Known Limitations → cao launch --yolo is install-time only subsection explaining the upstream TUI gap and the correct allowedTools: ["*"] + re-install workflow.

Verification

Unit tests

test/providers/test_kiro_cli_unit.py — 91 passed
Full unit/integration suite — 1363 passed, 13 skipped
black --check src/ test/ — clean

Live launch — yolo path (the 500 symptom)

Before this PR, cao launch --agents kb_eval_supervisor --yolo returned:

Error: Failed to connect to cao-server: 500 Server Error

and the server log showed:

Kiro CLI TUI initialization timed out, retrying with --legacy-ui
...
Kiro CLI initialization timed out with TUI and `--legacy-ui`

Root cause: both the TUI attempt and the legacy-ui fallback were launched with --trust-all-tools, and in 2.0.1 only the legacy path bypasses the consent dialog — but the first 30-second TUI timeout plus the second ~30-second legacy timeout exceeded the HTTP client's patience, and the retry path was reusing a pane that had already shown (and still had focus on) the consent dialog.

After this PR, the first and only command sent is:

kiro-cli chat --legacy-ui --trust-all-tools --agent kb_eval_supervisor

Terminal banner (confirming both flags landed):

All tools are now trusted (!). Kiro will execute tools without asking for confirmation.
[kb_eval_supervisor] 1% !>

Live launch — non-yolo path with profile.model

cao launch --agents yolo_model_test --headless

Command sent to tmux:

kiro-cli chat --model claude-haiku-4.5 --agent yolo_model_test

Terminal confirmation:

Model: claude-haiku-4.5 (/model to change) | Plan: KIRO POWER
[yolo_model_test] 6% !>

E2E suite (kiro_cli)

test/e2e/ -k "KiroCli" — 11 passed in 599s
  - TestKiroCliAllowedTools (3 tests)
  - TestKiroCliAssign (3 tests)
  - TestKiroCliHandoff (2 tests)
  - TestKiroCliSendMessage (1 test)
  - TestKiroCliSupervisorOrchestration (2 tests)

Comparison matrix (before → after)

Provider	--yolo bypass flag	profile.model flag
claude_code	--dangerously-skip-permissions ✅	✅ (PR #189)
codex	--yolo ✅	✅ (PR #189)
gemini_cli	--yolo ✅	✅ (PR #189)
kimi_cli	--yolo ✅	✅ (PR #189)
copilot_cli	--allow-all ✅ (pre-existing)	✅ (PR #189)
kiro_cli (before)	missing ❌	missing ❌
kiro_cli (this PR)	--trust-all-tools + --legacy-ui ✅	✅
opencode_cli	install-time only — upstream TUI has no flag (anomalyco/opencode#8463); this PR adds a runtime warning	✅ (PR #193)

Out of scope

• A CLI --model override on cao launch (to override profile.model at runtime when switching providers) is discussed but not implemented here.
• A CAO-side version-gate that warns when kiro-cli < 2.0.1 is installed is not added here; the consent-dialog regression is confirmed present in 2.0.1 itself and the --legacy-ui bypass covers all affected versions.
• A code-level workaround for opencode_cli --yolo (writing a temp .md with permission: {"*": "allow"} to $OPENCODE_CONFIG_DIR/agent/ at launch time) is deliberately out of scope. Once upstream [FEATURE]: Add --dangerously-skip-permissions (aka YOLO mode) anomalyco/opencode#8463 lands a TUI-compatible --dangerously-skip-permissions / --yolo flag in a stable release, a ~5-line provider change will wire it in behind the existing "*" in self._allowed_tools check.

Test plan checklist

• test/providers/test_kiro_cli_unit.py passes (91/91)
• Full unit/integration suite passes (1363/1363)
• test/e2e/ kiro_cli subset passes (11/11)
• Live cao launch --yolo on a workflow that previously returned 500 now initializes cleanly on the first attempt
• Live cao launch (non-yolo) with a profile containing model: shows --model on the kiro-cli command line
• black --check src/ test/ passes

[haofeif]

@patricka3125 when you get a chance can you help to review this ?

[patricka3125]

@haofeif lgtm