Skip to content

fix(providers): honor profile.model at terminal creation#189

Merged
haofeif merged 4 commits intoawslabs:mainfrom
patricka3125:fix/model-frontmatter
Apr 20, 2026
Merged

fix(providers): honor profile.model at terminal creation#189
haofeif merged 4 commits intoawslabs:mainfrom
patricka3125:fix/model-frontmatter

Conversation

@patricka3125
Copy link
Copy Markdown
Contributor

@patricka3125 patricka3125 commented Apr 20, 2026

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

patricka3125 and others added 4 commits April 19, 2026 23:30
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>
@patricka3125 patricka3125 changed the title fix(providers): honor profile.model at terminal creation (#174) fix(providers): honor profile.model at terminal creation Apr 20, 2026
@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Apr 20, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@86c9317). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #189   +/-   ##
=======================================
  Coverage        ?   91.71%           
=======================================
  Files           ?       55           
  Lines           ?     4417           
  Branches        ?        0           
=======================================
  Hits            ?     4051           
  Misses          ?      366           
  Partials        ?        0           
Flag Coverage Δ
unittests 91.71% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@haofeif haofeif added the bug Something isn't working label Apr 20, 2026
Copy link
Copy Markdown
Contributor

@haofeif haofeif left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @patricka3125 looked great to me

@haofeif haofeif merged commit f04921e into awslabs:main Apr 20, 2026
25 checks passed
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants