Follow up Kimi Code upstream updates: kimi.plugin.json plugin target (0.31.0 adds agents + dual-engine systemPrompt; only command surface)

Summary

Kimi Code 0.31.0 (2026-07-30) widened the kimi.plugin.json plugin manifest to contribute agents and systemPrompt/systemPromptPath on both agent engines, alongside the existing skills/commands/mcpServers/hooks. A plugin target would now cover rules, commands, subagents, skills, mcp and hooks in one artifact — and the manifest remains the only command surface Kimi Code has, so commands stays unreachable for the plain kimi-code target.

Baseline: #2425 (closed) was verified at 0.29.1; its gaps were implemented in #2438, and it deliberately deferred the plugin manifest as "a new target rather than a gap in the existing one". 0.31.0 changes that calculus.

Recent Releases

0.31.0 (2026-07-30) — plugin-contributed agents (an agents/ directory or explicit paths, auto-discovered and delegable as sub-agents, PR #2365); plugin systemPrompt / systemPromptPath (inline or file-referenced instructions, max 32 KB, "effective on both agent engines", PR #2314); Markdown custom agents on agent-core; /secondary_model. — releases
0.30.0 (2026-07-29) — [status_line] in tui.toml (TUI presentation; no rulesync feature dimension).
0.29.2 (2026-07-27) — no config-surface change.

Gaps

commands / rules / subagents / skills / mcp / hooks — `kimi.plugin.json` manifest surface unmapped

Upstream: as of 0.31.0, a plugin manifest contributes skills, commands, mcpServers, hooks, agents, and systemPrompt/systemPromptPath. — plugins doc
rulesync: the kimi-code target writes only the plain .kimi-code/ and ~/.kimi-code/ trees; commands is reported unsupported and there is no way to produce one (the plugin manifest is Kimi Code's only command surface). Nothing under src/ emits kimi.plugin.json.
Note: systemPrompt is additive instruction injection working on the TUI — unlike $KIMI_CODE_HOME/SYSTEM.md, which wholesale replaces the built-in system prompt and was correctly excluded as a rules surface in Follow up Kimi Code upstream updates: config.toml [mcp] default timeouts (0.29.1) and [tools] global enable/disable (0.29.0) #2425.

Proposed Follow-up

Add a kimi-code-plugin target following the claudecode-plugin / antigravity-plugin precedent, emitting kimi.plugin.json plus skills/, agents/, commands/, and hook scripts. Project scope only — plugins install per-user into $KIMI_CODE_HOME/plugins/managed/, so the generated tree is a source checkout the user installs from, not a live config path. Map rulesync rules to systemPromptPath rather than inline systemPrompt to stay under the 32 KB cap. Coordinate with the cross-tool plugin-packaging design (#329/#382) that already tracks the Copilot CLI / Codex plugin counterparts.

Non-gaps (verified at 0.31.0)

Hook events: still the same 16, all mapped in src/types/hooks.ts.
[tools] remains registered only on the v2 engine (packages/agent-core/src/config/schema.ts has no tools key at tag 0.31.0), so Follow up Kimi Code upstream updates: config.toml [mcp] default timeouts (0.29.1) and [tools] global enable/disable (0.29.0) #2425's caveat holds and rulesync's emission stays forward-compatible.
[status_line] (0.30.0): TUI presentation; rulesync has no statusline feature for any target.
model_preference / [secondary_model]: still experiment-gated; round-trips via looseObject.
Markdown custom agents on agent-core (0.31.0) retroactively validates the .kimi-code/agents/*.md output rulesync already produces.
Dry-runs clean: project 48 files; global 50 including ~/.kimi-code/config.toml for hooks and permissions.

References

https://moonshotai.github.io/kimi-code/en/customization/plugins.html — the plugin manifest surface (the gap).
feat: support plugin-contributed custom agents MoonshotAI/kimi-code#2365 — plugin-contributed agents (0.31.0).
feat(agent-core-v2): let plugins contribute system prompt instructions via the manifest systemPrompt field MoonshotAI/kimi-code#2314 — systemPrompt/systemPromptPath dual-engine support (0.31.0).
https://github.com/MoonshotAI/kimi-code/releases — 0.29.2 / 0.30.0 / 0.31.0 timeline.

Batch triage note (2026-07-31): fact-checked and kept open as an actionable large feature rather than resolved in this pass.

The premise holds: Kimi Code 0.31.0's plugin manifest now spans skills/commands/mcpServers/hooks plus agents and systemPrompt(Path), and the manifest remains Kimi Code's only command surface.
Not implemented autonomously because the issue itself calls for coordination with the cross-tool plugin-packaging design (rulesync plugin marketplaces similar to anthropic plugin marketplaces #329/Support for Claude Code plugins and Gemini CLI extensions #382) that tracks the Copilot CLI / Codex plugin counterparts — the target's shape (shared packaging layout vs per-tool emitters like claudecode-plugin) is a design decision a maintainer should settle first.

Once that design call is made, the implementation path described here (a kimi-code-plugin target, project scope only, rules via systemPromptPath to stay under the 32 KB cap) looks right and can proceed in a dedicated session.

Upstream update (re-check on 2026-08-06)

Newly found releases / changes

0.33.0 (2026-08-05) — latest; no new config surface relevant here.
0.32.0 (2026-08-04) — adds four [[hooks]] events: TurnStarted, UserPromptQueued, TaskStarted, SessionHeartbeat (changelog; event reference on the hooks page documents matcher subjects and payloads — TurnStarted matches turn origin kind, UserPromptQueued matches queued prompt text, TaskStarted matches task kind, SessionHeartbeat fires every 60s and its timer only runs when configured; all four observation-only).

Additional or changed gaps

hooks — the four new 0.32.0 events are unemittable. KIMI_CODE_NATIVE_HOOK_EVENTS (src/types/hooks.ts) is the canonical-map values plus PermissionResult and Interrupt; none of the new names are in it, so canonicalToKimiCodeHooks drops them with a "skipping unsupported event" warning. This also closes the escape hatch: the per-tool kimi-code override block is merged by buildEffectiveHooks before that filter runs, so a raw TurnStarted key there is dropped too — and an import → generate round trip loses hand-written entries for these events. Fix: add the four names to KIMI_CODE_NATIVE_HOOK_EVENTS (the same treatment PermissionResult / Interrupt already get); optionally map TaskStarted to the existing canonical taskCreated. The other three have no canonical counterpart and are better left override-only.

Verified unchanged

The kimi.plugin.json plugin-target gap tracked here still stands as the only command surface. Rules, mcp (0.29.1 timeout keys), subagents (model_preference rides the looseObject), skills, and the global-only labeling of hooks/permissions (project .kimi-code/local.toml still accepts only [workspace] additional_dir) all re-verified in parity at 0.33.0.

References

https://moonshotai.github.io/kimi-code/en/release-notes/changelog.html — 0.32.0 hook-events entry
https://moonshotai.github.io/kimi-code/en/customization/hooks.html — event reference table

Shipped the 0.32.0 hook events in #2612. TurnStarted, UserPromptQueued, TaskStarted and SessionHeartbeat are now in KIMI_CODE_NATIVE_HOOK_EVENTS, so a per-tool kimi-code.hooks override can name them directly and an import then generate round trip no longer loses them.

I deliberately did not fold TaskStarted into the canonical taskCreated. Kimi's fires when a background task starts, matches on task kind, and is observation-only; canonical taskCreated models Claude Code's TaskCreated, which fires while a task is being created, has no matcher support, and is blockable. Mapping them together would make one canonical rule mean two different things.

Still open on this issue: the kimi.plugin.json plugin target, which is a cross-tool packaging design question rather than an event-map gap.

One adjacent thing the review surfaced, not fixed here: canonicalToKimiCodeHooks emits a matcher for any event that carries one, but upstream documents SessionHeartbeat, PermissionResult and Interrupt as matcher-less, so a matcher written on those silently produces a hook that can never fire. The Claude Code path warns and drops in the equivalent case. Worth a separate scrap issue.

The Kimi Code matcher item recorded in the 2026-08-07 comment here has been fixed in #2639 (merged).

One correction to the event set that comment recorded: it named the same list as #2615, which was wrong. Verified against the upstream Event Reference table, the events whose "Matcher matches" column reads "Empty string" are exactly:

Stop
SessionHeartbeat
Interrupt

PermissionResult matches "Tool name", so a matcher there is meaningful and is deliberately kept; Stop was missing from the original list. Source: https://raw.githubusercontent.com/MoonshotAI/kimi-code/main/docs/en/customization/hooks.md

Leaving this issue open for its remaining items.

Upstream update (re-check on 2026-08-13)

Correction: `commands` is reachable without the plugin manifest

This issue's summary states that the manifest "remains the only command surface Kimi Code has, so commands stays unreachable for the plain kimi-code target". That is not accurate against the current docs, and it matters because it is the reason the commands column is blank today.

Kimi Code registers every external Skill as a slash command. From slash-commands ("External skill commands") and skills ("Invoking a Skill", "Body Placeholders"), verified at release 0.36.0 (2026-08-13):

a skill is invocable as /skill:<name>, with a /<name> shorthand when the bare name is not already taken;
argument text is appended to the body when the body contains no placeholders;
arguments, $ARGUMENTS, positional $0 / $1, and named $<name> substitution all work.

That is the same contract a rulesync command has. flow-type skills are manual-invocation only, which is precisely a slash command's semantics.

So the plugin target tracked here is a packaging question, not a prerequisite for commands. The two are independent, and commands can land first.

Proposed follow-up: add a KimiCodeCommand that emits each rulesync command onto the skills surface as <slug>/SKILL.md — .kimi-code/skills/<slug>/SKILL.md at project scope and $KIMI_CODE_HOME/skills/<slug>/SKILL.md at global scope — following the existing Devin / Hermes Agent pattern in src/features/commands/command-skill-ownership.ts. Three details matter for fidelity:

Directory-form SKILL.md requires an explicit name and description; upstream fails parsing without both.
Set type: flow (or disableModelInvocation: true) so command-derived skills stay manual-invocation rather than becoming model-auto-invoked.
Wire KimiCodeSkill's isDirOwned hook to rulesyncCommandSlugExists, so the skills feature neither imports command directories as skills nor deletes them as orphans.

Verified unchanged at 0.36.0

Re-swept the changelog back to 0.5.0 (2026-05-28) against the current adapters and found no other drift: rules, mcp (every documented field and transport emitted, ws correctly skipped), subagents, skills (including the dir/flat forms and the has-sub-skill parent with nested children riding through as otherFiles), hooks (all 14 canonical-mapped plus the 6 native-only events, the four 0.32.0 additions included after #2612), and permissions.

Two scope checks also came back clean and are worth recording so they are not re-derived:

Project-local config is <project-root>/.kimi-code/local.toml and holds only [workspace].additional_dir, auto-written by /add-dir. Hooks and permissions genuinely have no project-scope spelling, so the global-only treatment is correct rather than a missing scope.
$KIMI_CODE_HOME/SYSTEM.md (0.29.0) replaces the main agent's system prompt wholesale. That is a prompt-override surface, not instruction injection — rulesync has no equivalent dimension for any tool, so it is out of scope rather than a gap. (This is consistent with how Follow up Kimi Code upstream updates: config.toml [mcp] default timeouts (0.29.1) and [tools] global enable/disable (0.29.0) #2425 excluded it, and distinct from the plugin manifest's additive systemPrompt, which this issue already covers.)

References

https://www.kimi.com/code/docs/en/kimi-code-cli/reference/slash-commands.html — "External skill commands": skills register as /skill:<name> with a bare-name shorthand (basis of the correction)
https://www.kimi.com/code/docs/en/kimi-code-cli/customization/skills.html — "Invoking a Skill" and "Body Placeholders": the argument-substitution contract that matches rulesync commands

Upstream update (re-check on 2026-08-23)

No new gaps for the plain kimi-code target, and the kimi.plugin.json manifest schema this issue tracks did not change in the window, so the issue stands exactly as written. The value of this pass is the release inventory and three status changes on previously recorded items, recorded here so they are not re-derived.

Newly found releases / changes

Latest confirmed: 0.38.0 (2026-08-20) — npm @moonshot-ai/kimi-code, GitHub releases tagged @moonshot-ai/kimi-code@<version>.

Version	Date	Config-surface relevance
0.31.1	2026-07-31	none
0.32.0	2026-08-04	4 new hook events (#2558); `[loop_control]` key renames; new `[token_counting]`
0.33.0	2026-08-05	`agent-core-v2` becomes the default engine for TUI / `-p` / `acp` / `export` / `provider` (#2627); `KIMI_CODE_LEGACY_FLAG=1` falls back
0.34.0	2026-08-06	none
0.35.0	2026-08-12	MCP OAuth auto-detection without `auth: "oauth"` (#2731)
0.36.0	2026-08-13	`[secondary_model]` reworked into a subagent model pool (#2700); new `[identity]`, `builtin_product_skills`
0.36.1 / 0.37.x	2026-08-14 → 08-18	none (web UI only)
0.38.0	2026-08-20	`WaitFor` built-in tool; subagents no longer self-spawn by default

Changed status of previously recorded items

permissions — Follow up Kimi Code upstream updates: config.toml [mcp] default timeouts (0.29.1) and [tools] global enable/disable (0.29.0) #2425's [tools] caveat is now moot. That issue implemented [tools] enabled/disabled but ranked it low because the section was registered only in agent-core-v2, which was then web/experimental-only. 0.33.0 made v2 the default engine for the interactive TUI, so the [tools] section rulesync writes (src/features/permissions/kimi-code-permissions.ts:122) now takes effect on the default path. No code change is needed — the caveat in the source comments is simply outdated.
subagents — model_preference is dead on the default engine. Upstream removed it from the docs, and the v2 agent-file parser reads only name, description, whenToUse, override, tools, disallowedTools, subagents (packages/agent-core-v2/src/workspace/workspaceAgentProfileLoader/internal/agentFile.ts); only the legacy engine still honors it. Per-subagent model choice moved to the global [secondary_model] pool, which remains experiment-gated (KIMI_CODE_EXPERIMENTAL_SECONDARY_MODEL=1). No rulesync action: src/features/subagents/kimi-code-subagent.ts never emits model_preference, and its loose schema still round-trips it for imported files.
mcp — the dropped auth: "oauth" field is now formally unnecessary. 0.35.0 detects OAuth-requiring servers without it, retiring the last reason to revisit Follow up Kimi Code upstream updates: config.toml [mcp] default timeouts (0.29.1) and [tools] global enable/disable (0.29.0) #2425's decision to omit it from the field whitelist.

Verified non-gaps this window

hooks — the 0.32.0 events are already mapped. TurnStarted, UserPromptQueued, TaskStarted, and SessionHeartbeat are all in KIMI_CODE_NATIVE_HOOK_EVENTS (src/types/hooks.ts:886), with a comment explaining why TaskStarted stays native-only rather than folding into canonical taskCreated. rulesync's 20 reachable event names match upstream's HOOK_EVENT_TYPES (20 entries) one-for-one.
rules — v2 discovery (packages/agent-core-v2/src/agent/profile/context.ts:211-224) is identical to v1: $KIMI_CODE_HOME/AGENTS.md → ~/.agents/AGENTS.md → per-directory .kimi-code/AGENTS.md, AGENTS.md, agents.md. rulesync's .kimi-code/AGENTS.md + ~/.kimi-code/AGENTS.md output is unaffected by the engine switch.
hooks / permissions scope — still correctly global-only. .kimi-code/local.toml accepts only [workspace] additional_dir in v2 as well (packages/agent-core-v2/src/persistence/backends/node-fs/projectLocalConfigService.ts:15-21, ProjectLocalTomlSchema), so there is no project-scope config.toml counterpart.
mcp fields — the mcp.json optional-field table is unchanged since 0.31.0 and src/features/mcp/kimi-code-mcp.ts still covers every field. rulesync writes .kimi-code/mcp.json, which outranks the root .mcp.json in upstream's merge order (config-loader.ts merges user → .mcp.json → .kimi-code/mcp.json), so targeting the tool-specific path remains correct. Follow up Kimi Code upstream updates: config.toml [mcp] default timeouts (0.29.1) and [tools] global enable/disable (0.29.0) #2425's gap 1 ([mcp] default timeouts) is implemented at kimi-code-mcp.ts:215-232 (readKimiCodeMcpDefaults).
skills — the v2 skill parser adds only casing aliases (when-to-use, disable_model_invocation); no new frontmatter fields. extra_skill_dirs / extra_agent_dirs predate the window (present at 0.31.0) and are search-path additions rulesync has no need to declare.
ignore / commands / checks — still no upstream surface for the plain target.
New config sections ([identity], [token_counting], builtin_product_skills, the [loop_control] renames, the [secondary_model] pool) map to no rulesync feature dimension.
Dry runs clean: project → 48 files (1 rule + 1 MCP + 5 subagents + 41 skills); global → 50, including ~/.kimi-code/config.toml for hooks and permissions. Matches the documented matrix row exactly.

References

https://github.com/MoonshotAI/kimi-code/releases — the 0.31.1 → 0.38.0 changelogs behind the table above.
https://moonshotai.github.io/kimi-code/en/configuration/config-files.html — the current config.toml section inventory.
https://moonshotai.github.io/kimi-code/en/customization/hooks.html — the 20-event table validated against KIMI_CODE_NATIVE_HOOK_EVENTS.
feat(agent-core-v2): add lifecycle hook events and enrich hook payloads MoonshotAI/kimi-code#2558 — the new hook events in 0.32.0.
feat(cli): default CLI surfaces to the agent-core-v2 engine MoonshotAI/kimi-code#2627 — v2 as the default engine (0.33.0), which is what makes the [tools] caveat moot.
feat: replace the secondary-model experiment with a declarative subagent model pool MoonshotAI/kimi-code#2700 — the subagent model pool that replaced model_preference (0.36.0).
Upstream source read at tag @moonshot-ai/kimi-code@0.38.0, diffed against @moonshot-ai/kimi-code@0.31.0.

Upstream update (re-check on 2026-08-25)

Baseline for this pass: @moonshot-ai/kimi-code 0.38.0 (2026-08-20), the same endpoint the 2026-08-24 comment reached. Nothing newer has shipped, so this comment adds no releases — only two gaps the earlier passes did not reach, both in the [[permission.rules]] / MCP config surfaces rather than in the changelog.

Additional or changed gaps

1. mcp — executor and runtime_id are silently dropped on stdio servers.

packages/agent-core-v2/src/mcpCore/config-schema.ts accepts, beyond the fields rulesync writes, executor: "local" | "kaos" and runtime_id on stdio servers. (The 2026-08-24 comment already retired auth: "oauth" as unnecessary after 0.35.0's OAuth auto-detection — that half is settled; these two are separate keys and are not auto-detected.)

rulesync: project + global. toKimiCodeServer in src/features/mcp/kimi-code-mcp.ts copies a fixed whitelist (env, cwd, headers, bearerTokenEnvVar, enabled, startupTimeoutMs, toolTimeoutMs, enabledTools, disabledTools) and drops everything else without warning, so a server pinned to a non-default executor or runtime cannot be expressed and loses those keys on a round trip.

Follow-up: add executor and runtime_id to that whitelist. No canonical-schema change is needed — McpServerSchema is a z.looseObject, and src/features/mcp/vibe-mcp.ts already demonstrates the passthrough pattern. Worth confirming while there that the transport union is exactly stdio | http | sse, which it is, so rulesync's explicit transport emission and its refusal of ws both stay correct.

2. permissions — import understands only one of the three authoring forms Kimi accepts (lossy preserve).

packages/agent-core-v2/src/agent/permissionRules/configSection.ts's permissionFromToml accepts three shapes: [[permission.rules]] entries with a string pattern (the form rulesync writes), the [permission] allow / deny / ask array form, and rule entries shaped { tool = "Bash", match = "rm -rf*" } or { tool, pattern }, which it folds into Tool(arg).

rulesync: global. preserveKimiCodeRules in src/features/permissions/kimi-code-permissions.ts accepts only array entries under permission.rules that carry both a valid decision and a string pattern. Rules written in either other form are neither imported into canonical permissions nor preserved on write, so a rulesync generate --global can quietly discard permission rules that Kimi honours. This is the same class of defect as the verbose-rules import gap that was fixed for Grok CLI in #2498.

Follow-up: normalize both alternate forms during import and preserve — fold {tool, match} / {tool, pattern} into Tool(arg), and expand [permission] allow/deny/ask arrays into canonical rules. Related and already correct: PermissionRuleScope is turn-override | session-runtime | project | user, and only user is writable from a config file, so rulesync emitting scope: "user" is right.

Verified unchanged this run

The kimi.plugin.json plugin-target gap in the body still stands. The commands-via-skills correction from the 2026-08-13 comment and the [tools] engine-caveat note from the 2026-08-24 comment are both still accurate and need no restating. Also re-confirmed in parity at 0.38.0: rules discovery and precedence (with $KIMI_CODE_HOME/SYSTEM.md correctly excluded, since it replaces rather than appends to the system prompt); subagent and skill frontmatter field-for-field; all 20 hook events including the four 0.32.0 additions; the hook definition schema (event, matcher, command, timeout 1–600) against HookDefSchema; and [mcp] global defaults.

Two labels worth keeping accurate rather than re-deriving: ignore and checks genuinely have no upstream surface (Grep/Glob natively honour .gitignore/.ignore/.rgignore; there is no .kimiignore), and project-scope hooks/permissions are correctly blank because there is no project-scope config.toml — packages/agent-core-v2/src/persistence/backends/node-fs/projectLocalConfigService.ts limits <project-root>/.kimi-code/local.toml to [workspace].additional_dir.

Dry-run validation: project emits 48 files with ignore and commands reported unsupported; global emits 50, adding ~/.kimi-code/AGENTS.md and two gateway-merged writes to ~/.kimi-code/config.toml.

References

https://github.com/MoonshotAI/kimi-code — packages/agent-core-v2/src/mcpCore/config-schema.ts (executor, runtime_id), packages/agent-core-v2/src/agent/permissionRules/configSection.ts (permissionFromToml's three accepted forms), and packages/agent-core-v2/src/persistence/backends/node-fs/projectLocalConfigService.ts (ProjectLocalTomlSchema), all cited above.
https://moonshotai.github.io/kimi-code/en/release-notes/changelog.html — confirms 0.38.0 (2026-08-20) as the current endpoint.
https://moonshotai.github.io/kimi-code/llms.txt — the docs index; note that /kimi-code/en/llms.txt 404s, the index lives at the base path. Useful for future passes because the docs site is a VitePress SPA that resists plain fetching.

Upstream update (re-check on 2026-09-08)

Baseline for this pass: the 2026-08-25 comment reached @moonshot-ai/kimi-code 0.38.0 (2026-08-20). Five releases have shipped since. The kimi.plugin.json manifest this issue tracks did not change in the window, so the body still stands as written; the new material is one permissions gap.

Newly found releases / changes

Confirmed via gh api repos/MoonshotAI/kimi-code/releases (tags are @moonshot-ai/kimi-code@<version>).

Version	Date	Config-surface relevance
0.39.0	2026-08-27	`[experimental] subagent_fork` (#3007) and `[experimental] tower` (#3099); Remote Control (#3034) — all experiment-gated runtime switches
0.39.1	2026-08-28	none
0.40.0	2026-09-02	`[permission] dangerous_command_guard` (#3290) — the sole new authorable key in the window; also `[secondary_model]` on by default (#3334) and `[experimental]` entries now beating the master switch (#3427)
0.40.1	2026-09-02	none
0.41.0 (current)	2026-09-04	#3529 narrows the guard (it no longer blocks in `auto` mode); `kimi acp` stops honoring `KIMI_CODE_LEGACY_FLAG` (#3434)

Also new in the config docs but mapping to no rulesync dimension: the [swarm] section (timeout_ms), top-level disable_feedback_survey, and [drain].

Additional or changed gaps

permissions — [permission] dangerous_command_guard cannot be authored, and an existing value is destroyed on regenerate.

Upstream: dangerous_command_guard sits under [permission] alongside the [[permission.rules]] array, default true. Setting it to false turns off the built-in dangerous-command policy entirely — no confirmation for shutdown, reboot, rm -rf and friends in Always Ask and Ask When Needed mode. Added by #3290 in 0.40.0 (2026-09-02) and documented at 0.41.0 in configuration/config-files.md § permission. KIMI_CODE_DANGEROUS_COMMAND_GUARD=false overrides the file.
rulesync: unsupported (hooks and permissions are global-only for this target, correctly). KimiCodePermissions.fromRulesyncPermissions (src/features/permissions/kimi-code-permissions.ts:379-390) builds the document as default_permission_mode + tools + permission: { rules: [...] } — permission is only ever the rules table, so the key cannot be written even through the kimi-code override (KimiCodePermissionsOverrideSchema is a looseObject, but nothing spreads its unmodeled keys into [permission]). toRulesyncPermissions likewise reads only permission.rules, so the key is not lifted on import either.
The value is not merely unreachable, it is deleted. KIMI_CODE_CONFIG_DECLARATION (src/features/shared/shared-config-gateway.ts:1231-1246) gives the permissions feature ownedKeys: ["permission", "default_permission_mode", "tools"] under replace-owned-keys, so the whole [permission] table is replaced by the generated one. Verified against a seeded config.toml:
```
# before: HOME=<tmp>/.kimi-code/config.toml
[permission]
dangerous_command_guard = false
[[permission.rules]]
decision = "allow"
pattern = "Read"
```
after rulesync generate --targets kimi-code --features permissions --global:
```
[permission]
rules = []
```
Here the loss re-enables a guard (default true), so it fails safe rather than open — but it is still a user setting silently discarded, and the same table is where any future [permission] sibling will land.
Follow-up: carry [permission] siblings through the kimi-code override the way tools already is — either a modeled dangerousCommandGuard field or a general passthrough for non-rules keys of [permission] — and lift them back in toRulesyncPermissions so an import → generate round trip preserves them.

Verified unchanged this window

The plugin-manifest gap in the body is untouched. customization/plugins.md differs between 0.38.0 and 0.41.0 only in prose and in the Kimi Datasource marketplace copy; the manifest's contributed surfaces (skills, commands, mcpServers, hooks, agents, systemPrompt/systemPromptPath) are identical.
hooks — the Event Reference table is byte-identical in its event rows: still the same 20 events, still the same matcher-less set (Stop, SessionHeartbeat, Interrupt). No change needed to KIMI_CODE_NATIVE_HOOK_EVENTS.
subagents / skills — the agent-file frontmatter table (name, description, whenToUse, override, tools, disallowedTools, subagents) and the skill frontmatter table (name, description, type, disableModelInvocation, arguments, …) are unchanged; the 0.39–0.41 edits are wording only.
permission modes were renamed in the UI, not in the file. 0.41.0 relabels the three modes to Always Ask / Ask When Needed / Never Ask, but default_permission_mode still takes manual / yolo / auto (config-files.md line 99), so rulesync's defaultPermissionMode enum (src/types/permissions.ts:90) stays correct. Worth recording so a future pass does not "fix" it.
[tools], [mcp], [subagent], [experimental] field tables unchanged between the two tags.
The two gaps recorded on 2026-08-25 still stand, unimplemented: MCP executor / runtime_id dropped from the toKimiCodeServer whitelist, and preserveKimiCodeRules accepting only one of permissionFromToml's three authoring forms. The new gap above is in the same file and would land naturally alongside the second.
Dry runs clean: project 49 files (1 rule + 1 MCP + 5 subagents + 42 skills), global 51 (adding hooks and permissions in ~/.kimi-code/config.toml). ignore, commands and checks still correctly report unsupported.
Research-map note: .claude/skills/rulesync-feature-research/references/kimi-code.md does not exist, so this target has no documentation map; the docs index at https://moonshotai.github.io/kimi-code/llms.txt remains the entry point for a future pass (the site itself is a VitePress SPA that resists plain fetching, but raw.githubusercontent.com/MoonshotAI/kimi-code/<tag>/docs/en/** serves the same pages as markdown).

References

https://moonshotai.github.io/kimi-code/en/configuration/config-files.html — § permission documents dangerous_command_guard (the gap) and § top-level keeps default_permission_mode at manual/yolo/auto.
feat(agent-core-v2): require approval for dangerous bash commands in all permission modes MoonshotAI/kimi-code#3290 — the guard and its config key, 0.40.0 (2026-09-02).
feat(agent-core-v2): drop the dangerous command guard in auto permission mode MoonshotAI/kimi-code#3529 — 0.41.0 narrowing of the guard's behavior in auto mode.
https://github.com/MoonshotAI/kimi-code/releases — the 0.39.0 → 0.41.0 changelogs behind the table above.
https://moonshotai.github.io/kimi-code/en/customization/plugins.html — re-read at 0.41.0; the manifest schema this issue tracks is unchanged.
https://moonshotai.github.io/kimi-code/en/customization/hooks.html — the 20-event table, unchanged.

Partial progress (2026-09-12): the [permission] sibling-key item landed in #3005 — KimiCodePermissions.setFileContent now merges the [permission] table per key (Rulesync owns only rules), so a hand-written dangerous_command_guard = false (Kimi Code 0.40.0) survives regenerate instead of being deleted. It is still not modeled: neither authorable from Rulesync nor lifted on import, which docs/reference/file-formats.md now states.

Still open on this issue, all gated on design decisions rather than mechanics: the disabled → auto_start style choice for MCP defaults, the MCP executor / runtime_id fields, the preserveKimiCodeRules forms, and whether dangerous_command_guard should become an authorable override.

fix(kimi-code): preserve hand-written [permission] siblings on regene…

Upstream update (re-check on 2026-09-16)

Newly found releases / changes

Kimi Code 0.42.0 (2026-09-09), 0.43.0 (2026-09-14) and 0.43.1 (2026-09-15). The only configuration-surface change is a new per-server MCP key deferred: boolean (PR #3667), which defers connecting to that server until one of its tools is first needed.

Additional or changed gaps

mcp (project + global) — deferred is dropped. toKimiCodeServer (src/features/mcp/kimi-code-mcp.ts:95-108) whitelists the keys it emits, so deferred cannot be authored and is stripped when an existing file is regenerated. Proposed follow-up: pass deferred through in both directions and add it to the Kimi Code MCP note in docs/reference/file-formats.md (around line 1201).
Inconclusive: the legacy engine flag removal and the KIMI_CODE_PERMISSION_MODE_REMINDER environment variable are runtime/env-only and do not touch a file surface.

References

https://github.com/MoonshotAI/kimi-code/releases/tag/%40moonshot-ai%2Fkimi-code%400.43.1 — latest release in the window.
feat: declare dynamically_loaded_tools for official models and add per-server MCP deferred disclosure MoonshotAI/kimi-code#3667 — adds deferred to the MCP server schema.

Status update (2026-09-16), re-checked against the Kimi Code docs and the MoonshotAI/kimi-code repository.

Shipped in #3099: the deferred per-server MCP key (Kimi Code 0.43.0, deferred: z.boolean().optional() in packages/agent-core-v2/src/mcpCore/config-schema.ts, MoonshotAI/kimi-code#3667) is now passed through on generate and import. It is the only remaining sub-item that is a mechanical allow-list gap.

Still open, design-gated (left for a maintainer decision):

kimi.plugin.json plugin packaging target (new distribution surface; needs a decision on whether rulesync should author plugins at all).
MCP executor / runtime_id (sandbox execution) fields: no canonical rulesync counterpart, so the mapping/precedence must be decided first.
preserveKimiCodeRules covering all three rule forms.
dangerous_command_guard authorable override.
disabled → auto_start styling choice.

Leaving the issue open for those.

feat(mcp): pass the Kimi Code deferred MCP server key through

Status update: #3287 merged. It adds a new kimi-code-plugin target, following the existing *-plugin convention: project scope only, excluded from *, and kimi.plugin.json is not emitted. It writes:

rules: SYSTEM.md, intended for systemPromptPath
commands: commands/**/*.md
subagents: agents/*.md
skills: skills/*/SKILL.md

Remaining (kept open):

plugin MCP and hooks (manifest-only, so not emitted yet)
MCP executor/runtime_id
preserveKimiCodeRules coverage of the three rule formats
a dangerous_command_guard override
disabled vs auto_start naming for MCP
emitting commands as skills for the regular kimi-code target
a warning when SYSTEM.md exceeds Kimi's 32 KB limit (Kimi silently ignores an oversized file; only documented for now)

feat(kimi-code): add the kimi-code-plugin packaging target

Status update (2026-10-08), re-checked against MoonshotAI/kimi-code at @moonshot-ai/kimi-code@2.1.1 (latest).

Shipped in #3353:

MCP executor / runtime_id on stdio servers now pass through (schema-only keys in packages/agent-core-v2/src/mcpCore/config-schema.ts).
[[permission.rules]] entries written as tool + match/pattern are folded into Tool(arg) on import, matching Kimi's permissionFromToml, instead of being dropped.
rulesync generate warns when the kimi-code-plugin SYSTEM.md exceeds Kimi's 32 KiB systemPromptPath limit (PLUGIN_SYSTEM_PROMPT_MAX_BYTES in packages/agent-core-v2/src/app/plugin/manifest.ts).

Dropped: the disabled → auto_start naming item. No auto_start key exists in the Kimi Code docs or MCP schema at 2.1.1; enabled is the key Rulesync already writes.

Remaining:

Plugin MCP and hooks (need the kimi.plugin.json manifest, which the target does not emit).
Lifting the [permission] allow / deny / ask array form on import. Today those arrays survive regenerate as siblings of rules. Lifting them without taking ownership would duplicate rules, and taking ownership would delete hand-written arrays.
An authorable dangerous_command_guard override.
Emitting commands as skills for the plain kimi-code target.

Releases 2.0.0 through 2.1.1 add no new config surface for these features. The new keys are [watch], tui_mode and api_key_env, and project-local config now applies only after the workspace is trusted.

Status update (2026-10-09): Shipped in #3375: a kimi-code.dangerousCommandGuard boolean override that writes Kimi Code's [permission] dangerous_command_guard. It is still documented at 2.1.1 (config-files § permission). Import lifts a boolean value back into the override. If the override is omitted, the existing value in the file stays as it is.

Remaining:

Emitting commands as skills for the plain kimi-code target. Rulesync has no command-to-skill conversion mechanism yet.
Plugin MCP and hooks for kimi-code-plugin. These need the kimi.plugin.json manifest.
Lifting the [permission] allow / deny / ask array form on import.

Follow up Kimi Code upstream updates: kimi.plugin.json plugin target (0.31.0 adds agents + dual-engine systemPrompt; only command surface) #2502

Description

Summary

Recent Releases

Gaps

commands / rules / subagents / skills / mcp / hooks — kimi.plugin.json manifest surface unmapped

Proposed Follow-up

Non-gaps (verified at 0.31.0)

References

Activity

dyoshikawa commented on Jul 31, 2026

dyoshikawa commented on Aug 6, 2026

Upstream update (re-check on 2026-08-06)

Newly found releases / changes

Additional or changed gaps

Verified unchanged

References

dyoshikawa commented on Aug 7, 2026

dyoshikawa commented on Aug 8, 2026

dyoshikawa commented on Aug 13, 2026

Upstream update (re-check on 2026-08-13)

Correction: commands is reachable without the plugin manifest

Verified unchanged at 0.36.0

References

dyoshikawa commented on Aug 24, 2026

Upstream update (re-check on 2026-08-23)

Newly found releases / changes

Changed status of previously recorded items

Verified non-gaps this window

References

dyoshikawa commented on Aug 25, 2026

Upstream update (re-check on 2026-08-25)

Additional or changed gaps

Verified unchanged this run

References

dyoshikawa commented on Sep 8, 2026

Upstream update (re-check on 2026-09-08)

Newly found releases / changes

Additional or changed gaps

Verified unchanged this window

References

dyoshikawa commented on Sep 12, 2026

dyoshikawa commented on Sep 16, 2026

Upstream update (re-check on 2026-09-16)

Newly found releases / changes

Additional or changed gaps

References

dyoshikawa commented on Sep 17, 2026

dyoshikawa commented on Oct 2, 2026

dyoshikawa commented on Oct 8, 2026

dyoshikawa commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

commands / rules / subagents / skills / mcp / hooks — `kimi.plugin.json` manifest surface unmapped

Correction: `commands` is reachable without the plugin manifest