fix(cli): preserve configured subagent routing

[Hardik180704]

Summary

• preserve an explicit config-defined subagent (or its normal all default) when a later discovered Marketplace agent markdown file has the same slug and declares mode: primary
• keep markdown-provided fields, such as the prompt and description, when they do not conflict with explicit config routing
• add regression coverage for explicit subagent mode and config-only custom-agent default routing
• add a patch changeset for @kilocode/cli

Fixes #12638

Verification

• bun test ./test/kilocode/agent-routing.test.ts ./test/kilocode/agent-permission-overrides.test.ts ./test/agent/agent.test.ts — 61 passed
• bun run typecheck in packages/opencode — passed
• root pre-push typecheck excluding JetBrains — 22 packages passed
• bun run lint — passed (0 errors; existing warnings only)
• bun run script/check-opencode-annotations.ts --worktree — passed
• git diff --check — passed
• isolated end-to-end CLI run with a config-defined architect subagent and a colliding Marketplace-style primary agent — request route was primary-proof -> subagent-proof -> primary-proof

The repository-wide typecheck reached the unrelated JetBrains package but could not run it because Java 21 is not installed in the local environment. The non-JetBrains typecheck completed successfully.

A screen recording and still screenshot of the isolated end-to-end proof are attached in a PR comment.

[Hardik180704]

End-to-end verification proof

This uses an isolated workspace, isolated XDG directories, and a localhost-only OpenAI-compatible mock provider.

• Config defines architect as mode: subagent with model proof/subagent-proof.
• A Marketplace-style architect.md with the same slug declares mode: primary.
• The CLI visibly delegates to Architect Agent.
• Provider requests record the exact route: primary-proof -> subagent-proof -> primary-proof.

The screen recording shows the complete run; the still image makes the final route and PASS result easy to inspect.

issue-12638-routing-proof-final.mov

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Incremental review at 31dd8f7: since the last review the branch only picked up upstream main merges plus an empty ci: rerun checks commit. The PR's own changes (config.ts hook, mergeAgentMarkdown, and the routing tests) are byte-identical to the previously reviewed revision and survived the merges intact. The earlier WARNING about the guard being unable to distinguish a config-defined agent from a markdown-defined one remains resolved by the explicit configured map.

Files Reviewed (4 files)

• .changeset/fair-subagents-route.md
• packages/opencode/src/config/config.ts
• packages/opencode/src/kilocode/config/config.ts
• packages/opencode/test/kilocode/agent-routing.test.ts

Previous Review Summaries (2 snapshots, latest commit ae17dea)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit ae17dea)

Status: No Issues Found | Recommendation: Merge

The previously flagged WARNING (mergeAgentMarkdown's guard could not distinguish a real config-defined agent from an earlier markdown-defined one) is resolved in this update: config-defined agents are now tracked separately in a configuredAgents map (accumulated from legacy config, org modes, global/KILO_CONFIG/project JSON config, and per-directory JSON config files) and passed explicitly into mergeAgentMarkdown, so the primary-mode guard now only protects a genuine JSON-config entry instead of any earlier-loaded markdown agent. A new regression test (higher-priority markdown can override lower-priority markdown routing) confirms normal directory precedence is preserved for pure-markdown, multi-directory cases.

Files Reviewed (4 files)

• .changeset/fair-subagents-route.md
• packages/opencode/src/config/config.ts
• packages/opencode/src/kilocode/config/config.ts
• packages/opencode/test/kilocode/agent-routing.test.ts

Previous review (commit 43c6d82)

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
packages/opencode/src/kilocode/config/config.ts	133	mergeAgentMarkdown's guard can't distinguish a real config-defined agent from an earlier markdown-defined one, which can block a legitimate higher-priority-directory override in a pure-markdown, multi-directory scenario

Files Reviewed (4 files)

• .changeset/fair-subagents-route.md
• packages/opencode/src/config/config.ts
• packages/opencode/src/kilocode/config/config.ts - 1 issue
• packages/opencode/test/kilocode/agent-routing.test.ts

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-opus-5 · Input: 26 · Output: 4.7K · Cached: 600.7K}

_{Review guidance: REVIEW.md from base branch main}

[marius-kilocode]

Thanks for taking this on, and for the thorough verification writeup. The fix targets the right layer: resolving the collision at config merge time keeps config-defined routing intact instead of patching around it in the task tool. I re-ran the collision scenario locally against this branch (config subagent + marketplace-style primary markdown with the same slug) and the subagent stays routable with its configured model, prompt, and description. Merging.

Two follow-ups worth tracking separately: surfacing a config warning when a collision is resolved this way, and revisiting the marketplace installer's same-scope kilo.json entry deletion, which is now the remaining path that can silently drop a configured agent.

[Hardik180704]

@marius-kilocode Thank you for the approval. I merged the latest main into this branch because the previous HttpApi exerciser runs were timing out on an older PR merge snapshot. The update now includes 280c1176 (fix(cli): stop HttpApi exerciser hanging on blocking auth probes), and the focused routing suite still passes locally (62 tests). Fresh CI is running now—could you please take another look once the checks finish? Thanks again.

[Hardik180704]

@marius-kilocode The latest workflow is red because unit (windows, 4/4) had one unrelated timeout in test/server/httpapi-session.test.ts (returns false when an active prompt wins the deletion race, timed out after 10s). Both Linux shards and the HttpApi exerciser passed; the unit (linux) and test (linux) checks only failed as aggregate result jobs. I tried rerunning the failed jobs, but GitHub denied it because contributor accounts do not have the required repository permission. Could you please rerun the failed jobs when convenient? Thank you.

[marius-kilocode]

CI update: the unit shard failure was flake and passed on re-run, but the HttpApi exerciser now times out consistently. That is not on your change: your branch is based on v7.4.17, and main got a fix for the exerciser hanging on blocking auth probes today (280c117, "fix(cli): stop HttpApi exerciser hanging on blocking auth probes"). I reproduced the same hang locally on your branch, and each exerciser mode passes individually once the hang cause is absent.

Can you merge current main into your branch (or rebase onto it)? Auto-merge stays enabled, and I will approve the fresh CI runs as soon as the push lands.

[Hardik180704]

@marius-kilocode Done — I merged the current main into the branch and pushed b0d506e. The focused routing suite still passes locally (62 tests), the PR diff remains limited to the original four files, and fresh CI is running now. Thanks for the guidance and for re-reviewing once the checks settle.

[Hardik180704]

@marius-kilocode The required test workflow failed again on this PR in unit (windows, 4/4). The other Windows shards, both Linux shards, macOS, JetBrains, and the HttpApi exerciser all passed.

This attempt reported eight failures across three unrelated test files, mostly 15–30 second timeouts followed by cascading config-overlay errors. The previous attempt failed the same Windows shard on a different session HttpApi timeout, which suggests the shard is flaky rather than the failures being specific to this PR.

I tried to rerun only the failed jobs with gh run rerun 30560097515 --failed, but GitHub rejected it because contributors do not have repository admin rights. Could you please rerun the failed CI jobs when you get a chance? The existing approval is still retained. Thanks!

[Hardik180704]

@marius-kilocode This PR is approved and the latest CI failure is limited to the flaky unit (windows, 4/4) shard; the other Windows shards, both Linux shards, macOS, JetBrains, and the HttpApi exerciser all passed. The red unit (linux) and test (linux) jobs are aggregate result jobs reflecting that Windows shard failure. Since the failure is unrelated to this change and contributor permissions do not allow me to rerun or override the required check, it would be greatly appreciated if you could merge the PR manually when convenient. Thank you!