fix(providers): honor profile.model at terminal creation#189
Merged
haofeif merged 4 commits intoawslabs:mainfrom Apr 20, 2026
Merged
fix(providers): honor profile.model at terminal creation#189haofeif merged 4 commits intoawslabs:mainfrom
haofeif merged 4 commits intoawslabs:mainfrom
Conversation
Claude Code, Codex, Gemini CLI, Copilot CLI, and Kimi CLI all accept a --model flag at launch, but each provider's command builder was dropping profile.model on the floor — only Q CLI and Kiro CLI used it (at install time, baked into the agent JSON). Add a BaseProvider._model_args(profile) helper and wire it into each of the five runtime command builders. Copilot gates the flag behind its existing --model capability probe and treats profile-load failures as non-fatal. Model values are passed verbatim so any alias or full ID supported by the target CLI works unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Remove BaseProvider._model_args helper and inline the two-line conditional directly in each provider's command builder. Keeps provider-specific CLI flag details contained in the provider that owns them, so a future change to one CLI's syntax does not ripple through a shared helper. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The flag is documented in GitHub's Copilot CLI command reference, so the capability probe no longer earns its keep. Removing it also brings Copilot in line with the other four providers, which pass --model unconditionally and let the CLI surface a clear error if it's too old to understand the flag — better UX than silently ignoring the user's model preference. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…rofile terminal_service already loads the AgentProfile once to resolve allowedTools (terminal_service.py:148); Copilot was re-loading it inside _command() just to read profile.model. Thread the model value through create_provider into CopilotCliProvider.__init__ so the profile is read once per terminal. Scope is limited to Copilot because the other providers genuinely need profile.system_prompt and profile.mcpServers at command-build time, so removing their re-load is a larger refactor that can happen separately. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #189 +/- ##
=======================================
Coverage ? 91.71%
=======================================
Files ? 55
Lines ? 4417
Branches ? 0
=======================================
Hits ? 4051
Misses ? 366
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
haofeif
approved these changes
Apr 20, 2026
Contributor
haofeif
left a comment
There was a problem hiding this comment.
Thanks @patricka3125 looked great to me
6 tasks
haofeif
added a commit
that referenced
this pull request
Apr 25, 2026
* fix(kiro_cli): honor --yolo and profile.model at launch The kiro_cli provider silently dropped two CAO launch flags: 1. --yolo (allowed_tools=['*']) never became kiro-cli --trust-all-tools, so every tool invocation re-prompted for permission and blocked assign/handoff flows inside multi-agent workflows. 2. profile.model was never passed to kiro-cli. Workflows pinning a specific model silently ran on kiro-cli's default (auto). Translate allowed_tools=['*'] into --trust-all-tools and profile.model into --model <value> for both the TUI launch and the --legacy-ui fallback path. Profile load is best-effort — kiro-cli has its own agent store, so a CAO-unregistered profile must not block launch. PR #189 fixed the model gap for claude_code/codex/gemini/kimi/copilot but assumed kiro_cli handled model via install-time JSON baking; that assumption did not cover the runtime launch command. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(kiro_cli): skip TUI when --yolo to bypass consent dialog kiro-cli 2.0.1's new TUI shows a non-bypassable "Yes, I accept" consent dialog when launched with --trust-all-tools, breaking CAO's headless launch. Only --legacy-ui / --classic / --no-interactive skip the dialog. When CAO launches with --yolo (allowed_tools=['*']), now launch directly with --legacy-ui + --trust-all-tools instead of attempting TUI first. Non-yolo launches preserve the existing TUI-first behavior with --legacy-ui fallback. Also fail fast on yolo timeout (no second fallback), avoiding the ~30-second double-timeout that previously surfaced as a 500 to the caller. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * style(kiro_cli): reformat with black Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(launch): note kiro_cli legacy-ui fallback in --yolo warning Tell the user that kiro_cli will be launched with --legacy-ui when --yolo is set. Mirrors the provider-side behavior so the CLI output matches what actually runs. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * docs(opencode): flag --yolo as install-time only + warn at launch opencode's TUI has no runtime equivalent to --dangerously-skip-permissions / --yolo / --trust-all-tools (tracked upstream in anomalyco/opencode#8463), so permissions must be baked into the profile at `cao install` time. `cao launch --yolo` on opencode_cli is silently ignored today; this commit makes the gap visible. - docs/opencode-cli.md: correct the "pass --yolo" note, add a "Known Limitations" subsection explaining the install-time-only workflow and linking the upstream issue. - cli/commands/launch.py: when provider == opencode_cli and --yolo is set, emit a yellow warning that --yolo has no runtime effect and point the user at `cao install` with `allowedTools: ["*"]`. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses issue #174
Claude Code, Codex, Gemini CLI, Copilot CLI, and Kimi CLI all accept a --model flag at launch, but each provider's command builder was dropping profile.model on the floor — only Q CLI and Kiro CLI used it (at install time, baked into the agent JSON).
Add a BaseProvider._model_args(profile) helper and wire it into each of the five runtime command builders. Copilot gates the flag behind its existing --model capability probe and treats profile-load failures as non-fatal. Model values are passed verbatim so any alias or full ID supported by the target CLI works unchanged.
No documentation changes needed for this, since @docs/agent-profile.md actually contains reference for model frontmatter field. It just wasn't being honored in the implementation
References used:
Copilot CLI: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference
Codex CLI: https://developers.openai.com/codex/cli/reference
Claude Code: https://code.claude.com/docs/en/cli-reference
Gemini: https://geminicli.com/docs/cli/cli-reference/#model-selection
Kimi: https://www.kimi-cli.com/en/reference/kimi-command.html#model-selection