fix(cli): stabilize built-in capability installation - #2601
Conversation
The lazy-session refactor left capability calls going through requireSession(), so on a session-less v2 startup /plugins reported the capabilities unavailable and hid the built-in rows behind the promo. Like plugin management, capability readiness and installs are app-global on the v2 engine: the node-sdk harness gains a capability facade over the global channel, and the TUI resolves session-or-harness for every capability call.
🦋 Changeset detectedLatest commit: 390a4f5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
dev.mjs always points KIMI_CODE_PLUGIN_MARKETPLACE_URL at its own repo-serving server, which the override gate mistook for a user-configured marketplace and suppressed the built-in capability rows in every dev run. The dev server now marks itself, and the gate treats that marked URL as the default catalog while still honoring real overrides (slash-command source, user-set env, KIMI_CODE_DEV_MARKETPLACE_URL).
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 390a4f5891
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const knownKeys = new Set(['args', 'command']); | ||
| if (Object.keys(legacy).some((key) => !knownKeys.has(key))) return undefined; |
There was a problem hiding this comment.
Allow persisted stdio keys in CU migration
mcp.json entries created through the existing global MCP CRUD path are persisted after schema parsing, so an otherwise exact stdio kimi-cu registration can legitimately include schema-owned fields such as transport: "stdio" (and an explicit enabled: true) in addition to this command/args. With this closed key set, those legacy registrations are treated as customized and removeLegacyMcpRegistration leaves them in place, so installing the managed capability can still leave the duplicate standalone MCP server active. Route this through the MCP config access layer or allow schema-default fields while still rejecting real customizations.
AGENTS.md reference: packages/agent-core-v2/AGENTS.md:L49-L58
Useful? React with 👍 / 👎.
Related Issue
No linked issue.
Problem
The built-in Kimi Computer Use and Kimi WebBridge rows in
/pluginsdepended on an active session and mixed runtime readiness with installation state. This could hide the rows on a fresh v2 startup, report an installed plugin as unavailable, skip managed-plugin updates when another runtime layer was unhealthy, and leave legacy standalone WebBridge or Computer Use registrations competing with the managed plugin.What changed
/pluginsworks before the first session exists.install/installed/updatefrom plugin records and catalog versions; runtime setup details remain in logs.mcp.jsonchanges during setup, and keep connected MCP frontends alive during app replacement.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.