242 commits

Author	SHA1	Message	Date
7Sageer	6e31722df1	chore: drop deprecations for unreleased [subagent] pool keys (#2877) ... The [subagent] default_model / models deprecations added in #2700 guard a migration path that has no users: the pool keys only existed in #2700's own intermediate commits and never shipped in any release, so no config written against a released version can contain them. Remove the two deprecation entries (the mechanism stays — the released loop_control renames still use it), the migration notes in the en/zh config docs, the agent-core-dev skill note, and the obsolete test; regenerate the config manifest. No changeset: #2700 is still unreleased, so no published version ever emitted these warnings — the removal is invisible to users.	2026-08-13 12:57:22 +08:00
7Sageer	c9bfe8b2c8	feat: replace the secondary-model experiment with a declarative subagent model pool (#2700) ... * feat: replace secondary-model experiment with [subagent.models] pool Add a declarative subagent model pool to agent-core-v2: [subagent.models] maps [models] entry ids to selection hints rendered in the Agent/AgentSwarm tool descriptions, and [subagent].default_model picks the spawn model when the caller passes none. The tools' model parameter becomes a free-form alias string (stripped when no pool is configured), description rendering is caller-aware (primary (alias) [main model]), and a session-start validation service fails fast with CONFIG_INVALID on a missing/invalid default_model or an unresolvable pool alias. Remove the secondary-model experiment from the v2 engine, node-sdk, kap-server, and the TUI (the /secondary_model command), and drop the agent-profile modelPreference / model_preference frontmatter field on v2. The legacy v1 engine keeps the experiment unchanged; v2 ignores leftover [secondary_model] config silently. * fix(agent-core-v2): harden subagent model-pool validation and error/picker mapping Deep-review follow-ups to the [subagent.models] pool: - validate the pool before session materialization (after config.ready) and before the fork file copy, so a broken pool no longer leaves orphaned session dirs or leaked MCP overlay connections; the Session-scope validation service stays as a backstop - reject the reserved "primary" pool alias at startup, and again defensively in resolveSubagentBinding so a pool broken by a runtime config edit fails loudly at spawn instead of binding the wrong model - keep the [default] marker when the caller's own model is the pool default (primary (alias) [main model] [default]) - recompile the cached tool-args validator when a tool advertises a new schema object (mid-session pool edits no longer hit a stale validator) - map config.invalid to VALIDATION_FAILED in kap-server's session routes, the debug transport mapper, and the catch-all error handler - hide the v1-synthesized __secondary__ entry from the /model and /provider pickers again - fold per-export doc blocks into file headers per package comment conventions; add pre-flight/reserved-key/validator/mapping tests and document that create/resume/fork all fail on a broken pool * feat: re-add /secondary_model and accept a lone subagent default_model - v2 engine: a pool-less [subagent] default_model forms an implicit single-entry pool — validated at session create/resume/fork like an explicit pool, and advertised through the Agent/AgentSwarm model parameter. - Tool descriptions: the caller's own alias is a normal pool entry marked [main model]; the primary line stays distinct because only it inherits the caller's thinking level. - TUI: /secondary_model returns, persisting [subagent] default_model (merging into an existing pool with an empty description); the picker hides the no-op Thinking footer and rejects the reserved primary alias. - kap-server: /api/v1/config accepts and echoes subagent; the snake-to-camel patch conversion preserves user-defined map keys under providers/models/experimental/raw without leaking preserve mode into a colliding alias's own fields. - v1 config schema learns subagent.defaultModel/models so the shared config.toml round-trips; the v1 engine still ignores them at runtime. - Docs (en/zh) and changesets updated. * docs: use public model identifiers in the subagent model pool examples * refactor: rename /secondary_model to /secondary-model * test: cover the /secondary-model command name resolution * Revert "test: cover the /secondary-model command name resolution" This reverts commit 98a4a6d999. * feat(agent-core-v2): move the subagent model pool to [secondary_model] The pool keys (default_model, [secondary_model.models]) now live in their own [secondary_model] config section instead of [subagent], which keeps only timeout_ms; legacy [subagent] pool keys are ignored with a deprecation warning. The SDK config contract carries the pool on the secondaryModel field, so the TUI /secondary-model command (now also aliased /subagent-model) and the kap-server /config wire read and write it directly with no translation layer. * docs: correct default engine guidance * feat(agent-core-v2): pin subagents to default_model with [secondary_model] force force = true removes the main agent's per-spawn model choice: the Agent and AgentSwarm tools stop advertising the model parameter and every spawn binds default_model; an explicit choice, "primary" included, is rejected. The setting requires default_model, rejects a [secondary_model.models] table, and is validated loudly at session create/resume/fork (lifecycle preflight plus the Session-scope backstop). The v1 engine declares the key for write round-trips and excludes it from the recipe patch. Also documents pool entries as per-alias thinking-level variants via default_effort overrides. * docs: use real managed model aliases in the secondary_model examples The pool examples invented aliases (kimi-hs, fable, codex) and referenced non-existent model IDs (model = "codex"); they now reference only the managed aliases provisioned by /login (kimi-code/k3, kimi-code/kimi-for-coding, kimi-code/kimi-for-coding-highspeed), with the effort variant derived as kimi-for-coding-highspeed-deep. Also replaces the versioned kimi-k2.5 alias with kimi-for-coding per the docs model-ID rule. * chore: simplify the subagent model pool changeset * feat(agent-core-v2): honor the legacy [secondary_model] model key as a fallback default * refactor(node-sdk): export the reserved model-alias constants from the SDK Restore the SECONDARY_DERIVED_MODEL_ALIAS re-export and add PRIMARY_SUBAGENT_MODEL_CHOICE so the TUI imports both from @moonshot-ai/kimi-code-sdk instead of vendoring local copies. * feat(agent-core-v2): keep the subagent model pool behind the secondary-model experiment Restore the secondary-model flag gating so this change only adds the pool: with the experiment off the [secondary_model] pool keys stay inert — the Agent/AgentSwarm tools strip the model parameter, spawns inherit the caller's model, and startup pool validation is skipped. The /secondary-model slash command is gated behind the experiment again, and the docs and changeset describe the flag. * fix(node-sdk): cascade provider removal into the subagent model pool Deleting a provider left [secondary_model] entries pointing at the removed model aliases; with the secondary-model experiment on, every subsequent session create/resume/fork then failed pool validation. planProviderRemoval now filters dangling pool entries, and drops the whole section when its effective default (defaultModel, or the legacy recipe's model fallback) dangles — folded into the same atomic multi-section replace. * fix(agent-core-v2): close two subagent model pool validation gaps Spawn-time resolveSubagentBinding now rejects force combined with a [secondary_model.models] table, matching the startup pre-flight — a live session could otherwise reach that invalid state through a deep-merged config patch and only fail on the next create/resume. The session lifecycle pre-flight also awaits the kosong model/provider registries' ready alongside config.ready, so a cold bootstrap no longer fails a valid pool with CONFIG_INVALID against an empty registry. * test(agent-core-v2): stub the model/provider registries in handler-chain tests SessionLifecycleService now awaits IModelService/IProviderService readiness in its pool pre-flight, so the tests that assemble the real service through a hand-built container must register the two tokens. * fix(kap-server): cascade REST provider deletion into the subagent model pool The DELETE /providers route rewrote only the providers and models sections, so a pool referencing one of the deleted provider's aliases was left dangling and the engine's create/resume/fork pool validation failed every subsequent session until the user repaired the TOML by hand. Filter dangling pool entries and drop the section when its effective default dangles, mirroring the SDK's planProviderRemoval semantics. * fix: keep the subagent pool consistent on provider replace and preserve legacy recipe fields PUT /providers rebuilds the provider's alias set and can drop or rename aliases referenced by [secondary_model]; the pool now cascades there too — renamed aliases are repointed (mirroring the global default-pointer migration), dropped aliases are filtered, and the section is cleared when its effective default dangles. The v2 [secondary_model] schema also declares the legacy recipe patch fields (default_effort, max_output_size, ...) so validation no longer strips them: pool resolution keeps ignoring them, but config reads/writes now round-trip losslessly instead of silently deleting them from config.toml on any pool write. * fix(agent-core-v2): cascade the subagent pool on catalog refresh writes A background provider/model refresh rewrites the [models] table without touching [secondary_model], so a dropped alias left the pool dangling and every subsequent session create/resume/fork failed validation until the user repaired the TOML by hand — the same gap the SDK and REST write paths already had, but triggered unattended. The cascade helper now lives in agent-core-v2 next to the section it protects (cascadeSubagentModelPool): the discovery service folds the pool into the same atomic replaceSections transition, and kap-server's provider write routes reuse the shared helper instead of a local copy. * fix: cover the last two model-table write paths for the subagent pool ModelsDevImportService's catalog and custom-registry imports rebuild the [models] table without the pool cascade, so an import that drops a pooled alias left a dangling pool behind; both final write passes now fold the pool through cascadeSubagentModelPool (the drop passes deliberately skip it). The StubConfigService test double now treats a null section value as a delete, matching the real ConfigService. The TUI's provider overwrite flow removes an existing provider before re-adding it, which ran the removal cascade against a model table where every alias of that provider was absent and silently dropped the pool; the flow now snapshots secondaryModel up front and restores the entries that survive the re-add, via the cascade helper re-exported from the SDK.	2026-08-13 12:29:03 +08:00
liruifengv	ec84a6f9a3	feat(kimi-code): re-baseline pi-tui on upstream v0.84.1 and add fullscreen tui_mode (#2830) ... * feat(kimi-code): re-baseline pi-tui on upstream v0.84.1 and add fullscreen tui_mode Re-baseline the vendored pi-tui fork on upstream @earendil-works/pi-tui v0.84.1, keeping all local patches: narrow-terminal hardening, processed-line render caching (re-implemented into TuiMainScreen), editor history hooks, the paste-burst fallback, and multi-root @ completion. Upstream highlights absorbed: the renderer splits into TuiMainScreen and TuiAltScreen behind a TUI interface, the Markdown component gains opt-out LaTeX rendering (disabled on the kimi-code side), paste-registry repair on delete/undo, Windows input-latency and Shift+Enter fixes, and Kitty image layout fixes. Editor.setText gains a preservePasteRegistry option so paste-marker expansion survives wholesale text replacement. New tui_mode = "fullscreen" preference mounts TuiAltScreen: the transcript lives in a primary ScrollView with follow-end, the chrome docks at the bottom, mouse selection and scrollbar come from the renderer, and full-screen viewers (tasks browser, output viewer, approval preview) swap the layout root via screen-takeover. Viewport navigation keys fall through to the focused component when the primary scroll view cannot scroll. * feat(pi-tui): merge upstream main through 40a3d85 (post-0.84.1) Bring in upstream's merged-but-unreleased changes on top of the v0.84.1 re-baseline: - Fullscreen transcript search (ctrl+shift+f, next/previous navigation) - Alternate-screen render-churn reduction (9-18x less per-frame allocation by painting full-width rows as direct line references) - Unbound single-line scroll actions (tui.altScreen.lineUp/lineDown), wired into the fork's canScroll gating like the other viewport keys - SSH-aware escape-timeout default and PI_TUI_ESC_TIMEOUT override - Search snapping and SGR-mouse fragmentation fixes; LaTeX newline argument fix Conflicts resolved by union: upstream's search/line scroll bindings stay ungated, fork's primaryScrollable guard applies to all scroll actions. * fix(kimi-code): keep fullscreen dock from crushing the editor box The fullscreen layout gave the transcript ScrollView its intrinsic content height as basis and let the dock participate in shrink distribution with no minSize. Once the transcript exceeded the screen, the VStack shrink pass crushed the dock to a couple of rows, and the editor (3 rows: top border / input / bottom border) lost its bottom border row to clipping. Adopt pi's sizing contract: the ScrollView starts from basis 0 and grows, the dock keeps its intrinsic height, the editor never shrinks below 3 rows, and the footer below 1. Adds a VirtualTerminal-level regression test that replays a full streaming cycle in fullscreen. * docs(kimi-code): document the tui_mode preference in tui.toml * fix(pi-tui): let terminal focus reports fan out in fullscreen TuiAltScreen's viewport input listener consumed FOCUS_IN/FOCUS_OUT reports. Since the renderer installs that listener at construction — before any app-level listeners — terminal focus tracking and clipboard-image hints never saw focus transitions in fullscreen mode (notification_condition = "unfocused" went blind, refocus clipboard hints stopped). Keep the selection cleanup but stop consuming, matching the main-screen fan-out. Addresses Codex review on PR #2830. * fix(kimi-code): wire openUrl and right-click paste in fullscreen Mouse capture in the alternate screen intercepts the terminal's native link activation, leaving OSC 8 hyperlinks (like the footer's PR link) unclickable in fullscreen. Route renderer link clicks to the app's openUrl, and on Windows feed right-clicks to the focused component as a bracketed paste read from the clipboard. * feat(kimi-code): fullscreen prompt navigation, exit replay, progress resync - Mark user/assistant transcript messages with OSC 133 zones (start / end / final) so the fullscreen renderer's Ctrl-Shift-Up/Down prompt jumps work; GutterContainer keeps the markers at byte 0 when prefixing its gutter, and message render caches store already-marked lines. - On exit from fullscreen, preserve the frame and replay the transcript through a fresh main-screen renderer so native scrollback gets the regular inline layout (pi's "transcript" exit form). - Re-sync the OSC 9;4 progress indicator after a stop/start cycle: terminal.stop() clears it, and the cached progressActive flag used to suppress the re-send when returning from the external editor mid-turn. * feat(kimi-code): enable Markdown LaTeX rendering with a render_latex opt-out Align with the upstream pi-tui default: LaTeX math in Markdown messages renders as Unicode text. The explicit renderLatex:false we set during the re-baseline becomes a shared Markdown options helper fed by a new tui.toml preference (render_latex, default true), wired at startup and refreshed on /reload. * refactor(kimi-code): gate fullscreen behind KIMI_CODE_TUI_FULL_SCREEN Drop the public tui_mode preference from tui.toml before release; the fullscreen UI is experimental, so enable it with the KIMI_CODE_TUI_FULL_SCREEN=1 env var instead. Docs move from the config-file reference to the env-vars page. * chore(changesets): clarify fullscreen mode and LaTeX formula entries * chore(changesets): trim fullscreen mode entry * chore(changesets): trim LaTeX formula entry * chore(changesets): drop redundant kimi-code entries * test(kimi-code): add stepRetry to fullscreen layout fixture after main merge * fix(kimi-code): apply render_latex before theme-driven Markdown rebuilds Codex review on PR #2830: applyReloadedTuiConfig set the shared LaTeX toggle after applyTheme(), but theme application invalidates transcript components and their rebuilt Markdown children copy the options at construction — so a /reload that only flipped render_latex kept the old value until some later invalidation. Move the setter before applyTheme and pin the ordering with a test. * fix(kimi-code): carry renderLatex through TUI config saves Codex review on PR #2830: currentTuiConfig omitted renderLatex, so saving an unrelated preference (theme/editor/upgrade/cache-hint) serialized render_latex as the default true and silently reset a user's opt-out. Carry the appState value through the shared save payload. * feat(kimi-code): report tui_mode in lifecycle telemetry Tag startup_perf and exit events with the active renderer mode (regular/fullscreen) so fullscreen adoption is measurable while it is gated behind KIMI_CODE_TUI_FULL_SCREEN.	2026-08-12 18:23:41 +08:00
Haozhe	c212ae9715	fix(kimi-code): show MCP launch targets in the workspace trust prompt (#2843) ... * fix(kimi-code): show MCP launch targets in the workspace trust prompt Render each gated project MCP server's launch target (transport, command, args, cwd, or url) in the workspace trust prompt without leaking env or header secrets, stripping terminal control characters from the workspace-supplied text, default the prompt to "Don't trust", and resolve fd binaries to absolute paths so untrusted workspaces cannot plant a bare-name fd executable that runs before trust confirmation. * fix(kimi-code): resolve stty to an absolute path before the trust gate	2026-08-12 13:34:32 +08:00
Haozhe	dc8db90cdd	docs(server): add local server guide and API reference (#2839) ... * docs(server): add local server guide and API reference * docs(server): qualify binary endpoint HTTP semantics	2026-08-12 12:29:09 +08:00
liruifengv	3fc841ff23	docs(changelog): sync 0.35.0 from apps/kimi-code/CHANGELOG.md (#2841) ... * docs(changelog): sync 0.35.0 from apps/kimi-code/CHANGELOG.md * docs(changelog): add Modern Web Guidance plugin entry to 0.35.0	2026-08-12 12:15:07 +08:00
qer	d9ec566e51	docs(changelog): sync 0.34.0 from apps/kimi-code/CHANGELOG.md (#2704) ... * docs(changelog): sync 0.34.0 from apps/kimi-code/CHANGELOG.md * chore: link	2026-08-06 22:55:50 +08:00
wenhua020201-arch	51ef78b8c9	docs: add Official Plugins section with WebBridge and Computer Use (#2653) ... * docs: add Official Plugins section with WebBridge and Computer Use Group the three official capabilities (Kimi Datasource, Kimi WebBridge, Kimi Computer Use) under a new Official Plugins section on the plugins page, with a single shared install/upgrade flow. Add an authorization walkthrough screenshot for Computer Use and regroup the Datasource coverage table by category with named data sources. * docs: add browser extension install steps for Kimi WebBridge Installing via /plugins is not enough on its own: AI can only drive the browser after the Kimi WebBridge extension is present. Document both install paths (Chrome Web Store / Edge Add-ons, and manual load-unpacked via chrome://extensions with Developer mode) plus a quick way to verify. * docs: split WebBridge manual install into illustrated steps Break the manual extension install into numbered steps with per-step screenshots: enable Developer mode on chrome://extensions, then load the unpacked kimi-webbridge-extension folder. * docs: tighten WebBridge install screenshots to the relevant area * docs: add WebBridge ready-state verification screenshot * docs: note WebBridge's two-part install in the shared install steps * docs: even out WebBridge install screenshot edges * docs: replace WebBridge install screenshots with clean crops Re-shoot source images: split the two-step manual install guide into per-step screenshots with clean edges, and replace the ready-state popup screenshot with the toolbar-icon success indicator. * docs: use newly provided WebBridge step screenshots * docs: sharpen Computer Use auth screenshot and center it Replace the downscaled auth-window image with a crisp native capture, constrain its display width to 380px, and center it on the page. Also move the WebBridge two-part install note into an info callout directly under the shared install steps. * docs: drop the coverage start year from the Datasource table * docs: spell out the two WebBridge extension install options * docs: show the Kimi Code toggle enabled in the Computer Use auth screenshot * docs: show version badges for WebBridge and Computer Use, rework Computer Use scenarios Add version badges next to all three official plugin names. Rewrite the Computer Use capability list around verified task shapes and add a warning callout for operations that should not be delegated. Keep the final WebBridge install step inside the numbered list. * docs: add Windows (WinCU) notes to Computer Use Computer Use now ships a Windows runtime with a different install path and behavior: it may briefly take over the real mouse and keyboard instead of running fully in the background. Document the install command, system requirements, permission model, and privilege matching, and stop claiming the feature is macOS-only. * docs: break up the plugin manager wall of text Split the Installation and Management paragraph into bullets, drop the parts duplicated by the Official Plugins section (including the outdated macOS-only note), and link to that section instead. * docs: list the plugin manager tabs and drop the tab-behavior block * docs: give the WebBridge extension install section an English anchor * docs: restore the /reload or /new activation step for official plugins * docs: align the plugins page wording with the published docs site * chore: retrigger CI --------- Co-authored-by: qer <wbxl2000@outlook.com>	2026-08-06 22:51:27 +08:00
Haozhe	794714ebef	fix(agent-core-v2): gate plugin changes behind session baselines and reminders (#2702) ... * fix(agent-core-v2): gate plugin changes behind session baselines and reminders - capture a per-session MCP server baseline (ISessionMcpHandle.isBaselineServer) so servers added mid-session (plugin install, mcp.json edit) never register tools in live sessions; they take effect on /new, /reload, or resume, while removed servers stay tombstoned and fail calls with a removal notice - stop rebuilding the system prompt on plugin-source catalog changes: the frozen skill listing and plugin sections cannot move anyway, and the rebuild only churned the ${now} timestamp, invalidating the provider prompt cache - freeze the Agent tool description's catalog profile list once the session catalog has loaded, keeping the tools payload byte-stable across mutations - append a plugin_change system reminder to live sessions on plugin mutations (new IPluginService.onDidMutate; explicit reloadPlugins does not raise it) - revert the TUI hint to "Run /new or /reload to apply plugin changes." and update the plugin/MCP docs and changesets to the corrected contract * fix(agent-core-v2): import LifecycleScope from app/scopes in sessionOutcomeMirror #2666 imported LifecycleScope from #/_base/di/scope, which does not export it (it lives in #/app/scopes), breaking the package build and typecheck on main. * fix(agent-core-v2): close the mutation-driven session-start refresh and overlay baseline leaks Codex review on the PR found two contract leaks: - a plugin mutation re-pulls the plugin skill source, and the existing catalog listener answered with a fresh plugin_session_start reminder — injecting the newly installed plugin's instructions into the live session alongside (and contradicting) the plugin_change notice. The session-start refresh now skips mutation-driven catalog changes (one per mutation, counted; explicit reloads keep the old refresh behavior). - a session created with ephemeral mcpServers kept its MCP baseline open until the overlay connect finished; a workspace server added in that window (plugin install, config edit) leaked into the live session through the merged view. The overlay handle's baseline now freezes on the workspace manager's initial load, with the ephemeral names baseline by construction. * fix(agent-core-v2): drop duplicate LifecycleScope import in sessionOutcomeMirror test --------- Signed-off-by: Haozhe <yanghaozhe@moonshot.ai>	2026-08-06 21:11:03 +08:00
Haozhe	02c026d487	feat(agent-core-v2): tombstone removed MCP servers and freeze plugin prompt inputs (#2694) ... * feat(mcp): tombstone removed MCP servers and apply plugin changes immediately (20 files) - add 'removed' MCP server status: workspace config removals call markRemoved instead of remove, keeping tool registrations alive while short-circuiting calls with a removal notice - fire onDidReload after every plugin mutation (install/enable/disable/remove) so workspace consumers refresh contributions immediately - TUI renders the removed status in the MCP panel/startup summary and shows an apply-immediately hint on the v2 engine * feat(agent-core-v2): freeze plugin prompt inputs for live agents (2 files) - snapshot the model skill listing and plugin system-prompt sections on the first successful prompt build and reuse the frozen values for the agent's lifetime, so plugin install / enable / disable / remove / reload never rewrites a live agent's prompt (same keep-live-sessions-stable philosophy as the MCP tombstone) - freeze only on success: a not-yet-ready skill catalog or a failed enabledSystemPrompts() read must not pin empty values for the agent's lifetime - refreshSystemPrompt still rebuilds on catalog change events but reuses the frozen values, so the prompt only moves when non-plugin inputs change (AGENTS.md, [tools] section, session tool policy, compaction); new agents snapshot the then-current state * chore(changeset): add changesets for MCP tombstone and frozen plugin prompt inputs * docs: describe immediate plugin changes and the removed MCP status on the v2 engine * fix(klient): mirror the removed MCP server status in the wire contract * docs: drop the legacy-engine behavior notes from the plugin and MCP pages * fix(agent-core-v2): freeze plugin sections only on a loaded snapshot - enabledSystemPrompts() resolves to its consumption fallback (never rejects) while the initial plugin load has failed; freezing that empty read locked plugin sections out of the live agent even after a later successful reload - expose hasLoadedSnapshot() on IPluginService so resolvePluginSections can tell a real empty snapshot from the fallback before freezing	2026-08-06 19:19:51 +08:00
liruifengv	3c75a27da6	feat(tui): add cache-expiry hint dialog for resumed and idle sessions (v2 engine) (#2646) ... * feat(agent-core-v2): detect prompt-cache breaks from per-step usage and emit telemetry Track consecutive turn-scoped LLM requests per agent; when the cache-read token count drops by more than 5% and by more than 2000 tokens between requests, log a debug line and emit cache_break_detected with both usages, the drop ratio, and the interval. Operation requests (e.g. compaction) act as a baseline barrier so expected drops are not reported. * feat(tui): add cache-expiry hint dialog for resumed and idle sessions (v2 engine) Resuming a long-idle session or submitting after a long idle stretch re-sends the whole history with an expired context cache. Show a dialog offering to compact, start a new session, continue as-is, or never ask again (persisted as cache_expiry_hint in tui.toml). Thresholds come from the client_configs endpoint (estimated_cache_duration) via a generic per-name cached client; only OAuth-managed providers participate. * fix(tui): preserve submit order and revalidate session in cache-hint flows Cold-cache submits during the in-flight config fetch are now swallowed and replayed through a FIFO chain, so a later prompt can never overtake the stashed one. Both the resume and idle paths re-check the current session after the async fetch: a switch mid-flight drops the dialog (resume) or hands the stashed input back to the editor instead of sending it into the wrong session (idle). * chore(agent-core-v2): regenerate state manifest after merging main * fix(tui): apply cache_expiry_hint on /reload and /reload-tui * fix(agent-core-v2): skip unmeasured all-zero usage in cache break detection * fix(tui): restore chained cache-hint submits when the dialog is not sent When several submits are swallowed during the cold-config fetch and the first dialog is dismissed (or its compact/new action fails), the stashed inputs were restored while later chained submits were still released — reordering the conversation. Chained submits now follow the fate of the message that opened the dialog, and multiple restores append newline-joined instead of overwriting the editor. * fix(agent-core-v2): reset cache-break baseline on model change Caches are per-model, so a cache-read drop after /model is expected, not a break. The baseline now carries the model and only same-model records are compared. * fix(tui): only count LLM-activity replay records for the resume cache hint The v2 resume replay also carries local-only state records (permission, plan, config updates, approval results) that slash commands append without an LLM request. Filter lastActiveAt to message/compaction records so a recent local change no longer masks an expired cache. * style(agent-core-v2): rewrite the cacheBreak impl header per package convention State the domain role, collaborators, and scope instead of narrating implementation steps; the behavior guards now live in the code alone. * fix(tui): drop the resume cache hint when a turn started mid-fetch The resume dialog is fire-and-forget over an async config fetch; if the user already sent the first prompt by the time it resolves, mounting would overlay an active turn and its actions would hit the live session. Re-check streamingPhase/isCompacting after the await, next to the session check. * style(agent-core-v2): trim the cacheBreak contract header to contract and scope * refactor: report cache-break detection from the TUI client Move the detector out of the engine so the telemetry event carries the client's own identity (which client produced it is now attributable). The TUI observes main-loop turn.step.completed usage directly, with the same guards: first-step/unmeasured/all-zero records skipped, model change and compaction reset the baseline. The agent-core-v2 cacheBreak module is removed. * chore: drop accidentally committed dist-web build output and ignore it * chore: revert the dist-web ignore rule * chore: restore dist-web to the tracked content from main * feat(tui): record cache breaks caused by mid-session model/effort switches A model or effort change mid-session busts the prompt-cache key — that is a real cache break worth attributing, not noise. The baseline now carries model and effort, the same-model exemption is gone, and cache_break_detected reports prev/curr model and effort alongside both usages. * chore(changeset): simplify the cache-expiry hint entry * chore(changeset): trim the cache-expiry hint entry to one line * fix(tui): cache-hint review follow-ups - carry the pre-dialog media extraction through compact/new resends so pasted attachments survive the image-store clear on a new session - reset the cache-break baseline after /undo — the context cut makes the next cache-read drop expected - release the stashed submit when a foreground operation started during the cold-config fetch instead of mounting the dialog over it - count a completed compaction as activity so the next submit is not judged against the pre-compaction timestamp * chore(changeset): drop the v2-engine-only suffix * fix(tui): seed the activity baseline when the resume check skips * fix(tui): cache-hint review follow-ups * fix(tui): record cache activity on completed steps, not turn begin * feat(cli): persist the client-configs cache across restarts	2026-08-06 13:26:37 +08:00
Haozhe	34c4181437	fix(kimi-code): keep kimi -p alive while background tasks are pending (#2675) ... The 10-year default print wait ceiling (315360000s) overflowed Node's setTimeout limit (2^31-1 ms) into a 1ms fire, so the steer/drain wait returned instantly and kimi -p exited right after the main turn, killing pending background tasks and subagents. - add setClampedTimeout in agent-core-v2 _base, clamping delays to MAX_TIMER_DELAY_MS, and route every config-driven timer through it (timeoutOutcome, task wait/manager timeout, swarm attempt timeout) - chunk the print turn-endings wait against the real deadline instead of returning null on the first clamped timer fire - restore v1 semantics: a non-positive swarm subagent timeout is unbounded - default print_wait_ceiling_s to 2147483s (~24.8 days, the timer maximum)	2026-08-06 11:02:34 +08:00
qer	68ba740ebf	feat(kimi-code): support Kimi Computer Use on Windows (#2652)	2026-08-05 21:15:02 +08:00
liruifengv	7c919f0376	docs(changelog): sync 0.33.0 from apps/kimi-code/CHANGELOG.md (#2636) ... * docs(changelog): sync 0.33.0 from apps/kimi-code/CHANGELOG.md * docs(changelog): move the v2 engine entry to Refactors and the trust prompt to Polish	2026-08-05 16:46:10 +08:00
qer	2b3e9a9f79	fix(tui): clarify curated plugin marketplace (#2635)	2026-08-05 16:18:50 +08:00
qer	75fe068a01	fix(cli): stabilize built-in capability installation (#2601) ... * fix(cli): show built-in capabilities before the first session exists 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. * fix(cli): count the dev marketplace server as the default catalog 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). * fix(cli): align built-in capability updates	2026-08-05 14:55:04 +08:00
Haozhe	f881cdd970	feat(cli): default CLI surfaces to the agent-core-v2 engine (#2627) ... * feat(cli): default to agent-core-v2 engine with KIMI_CODE_LEGACY_FLAG opt-out - invert the engine gate: isKimiV2Enabled() now returns true unless KIMI_CODE_LEGACY_FLAG is truthy; KIMI_CODE_EXPERIMENTAL_FLAG no longer selects the engine - replace the experimental `kimi acp-v2` command with the native v2 implementation as the default `kimi acp`; the legacy acp-adapter path remains under the legacy flag - drop the acp-v2 experimental flag from the registry - rename the dev:cli:v2 script to dev:cli:legacy - update en/zh docs for the new default engine and the legacy flag * feat(cli): route export and provider through the engine gate - select the harness via isKimiV2Enabled(): agent-core-v2 by default, the legacy harness when KIMI_CODE_LEGACY_FLAG is truthy - close the harness after each one-shot command so the v2 engine's watchers do not keep the process alive - document both commands in the KIMI_CODE_LEGACY_FLAG env-var entry	2026-08-05 14:42:23 +08:00
Kai	8db7d42f23	feat(tui): add /bug as an alias for /feedback (#2614)	2026-08-04 23:54:21 +08:00
Kai	98ee35afd2	feat(agent-core-v2): add custom agent identity (#2573) ... * refactor(agent-core-v2): simplify context tags and shared copy Rename the context-injection tags to `<skill-loaded>` and `<plugin-instructions>`, drop the product prefix from the CronCreate tool description and the default agent description, and point the MCP OAuth callback page back to "your terminal" instead of naming one client. The callback page is shared by the ACP host, the web UI, and embedding hosts, so naming a single client was inaccurate there. The tags and the two descriptions read exactly the same without the prefix. Verified no runtime consumer matches the old tag names; the updated snapshots cover the tool descriptions that changed. * feat(agent-core-v2): add a switch for the product-documentation skills Five builtin skills document this CLI itself — `update-config`, `custom-theme`, `mcp-config`, `check-kimi-code-docs`, and `import-from-cc-codex`. Their names and descriptions sit in the system prompt on every turn, which is dead weight for runs that will never reconfigure the CLI. Add a top-level `builtin_product_skills` field (also settable through `KIMI_CODE_BUILTIN_PRODUCT_SKILLS`) to drop them. On by default, so nothing changes unless it is set; the trade when off is that the model loses the guided flows for those tasks. Filtering happens where the catalog is assembled — a later filter would leave the skills advertised to the model. The whole section is one scalar, so it exercises the section-level env binding branch and needs its own strip: `stripEnvBoundFields` only walks object fields, so an env override would otherwise be written back into `config.toml`. * feat(agent-core-v2): add custom agent identity Add an `[identity]` config section (`name`, optional `slug`, both also settable through `KIMI_CODE_IDENTITY_NAME` / `KIMI_CODE_IDENTITY_SLUG`) that sets the identity the agent presents: the name it calls itself in the system prompt, the `User-Agent` product token sent to third-party providers, and the client name announced to MCP servers. Leaving it unset changes nothing. Until now every one of these was fixed, which left no way to run the agent as part of another product — an internal deployment, a fork with its own branding, an embedding host. The identity resolves inside the engine rather than being seeded by each host, so it applies to every launch surface — including headless runs, which today seed no display name at all and fall through to the built-in default. Two deliberate asymmetries: - The display name is a filling value with a fallback chain (config > host-declared > the consumer's own default); the slug is a rewriting value with two states only, so with no identity configured the rewriting paths are equivalent to not existing. - The rewrite happens in the outbound header assembly, the one layer that knows which vendor it is building for. Vendors declaring `hostHeaders: 'full'` keep the host's own product token, which that header set is built around and which backends key on; the configured identity applies to the third-party path. Resolution is lazy throughout: config loads asynchronously, and a constructor snapshot would freeze the pre-load value under some startup orderings. Two input edges the resolver has to absorb, since both would otherwise reach the User-Agent builder and either break it or quietly rewrite the header: blank and whitespace-only values read as unset in the file just as they already did in the env, so a stray `name = ""` cannot claim an identity; and a name that folds away to nothing under slug normalization (a CJK-only name, say) falls back to a neutral token rather than producing a blank product, which the builder rejects. * fix(agent-core-v2): keep the file value when a scalar env binding fails to parse `config.ts` documents that an env value failing its binding's `parse` is ignored, and `applyEnvBindings` honors that for object fields by assigning only when the resolved value is defined. `applySectionEnv` returned the parse result straight through for whole-section scalar bindings, so a blank or mistyped variable resolved to `undefined` and cleared the configured file value instead of being ignored. Nothing hit this before: every existing section either binds object fields or is env-only. `builtin_product_skills` is the first whole-section scalar binding, where exporting an empty or misspelled `KIMI_CODE_BUILTIN_PRODUCT_SKILLS` would silently undo a configured `false`. * feat(agent-core-v2): extend the custom identity to discovery and global MCP Two outbound paths still announced the built-in product name under a configured identity: - `DiscoveryService` read the host User-Agent straight from bootstrap args when refreshing provider models, so custom registries — which are third-party endpoints — saw the original token while chat requests to the same class of endpoint saw the configured one. - `SDKRpcClientV2` builds its own global `McpOAuthService` plus a throwaway `McpConnectionManager` for server testing, neither of which goes through the workspace-owned manager that carries the resolver. Both now resolve the identity from the App scope. * refactor(agent-core-v2): neutralize remaining copy and align comments The synthetic MCP authentication tool description is injected into the model context and still named the product; it and the OAuth callback pages now use client-neutral wording. "Return to your terminal" was no improvement over naming a client — both assume what the host is, and that page serves the ACP host, the web UI and embedding hosts alike. Comments introduced by the identity work move into their module headers, per the domain convention. Interface field docs stay: the rule names functions, methods and statements, and field-level docs are established across the codebase. The new tests gain scenario headers and dispose the scoped hosts they create, and the `[identity]` docs state which engine reads the section. * fix(agent-core-v2): read the product-skill switch after config is ready `BuiltinSkillSource` is the lowest-priority skill source, so the workspace catalog loads it first — before `IConfigService` has finished loading — and keeps the contribution it returns for the life of the handler, with no reload path and no change event. Reading `builtin_product_skills` eagerly therefore stranded the startup configuration: an explicit `false` could be ignored for the whole process. `UserFileSkillSource` already awaits config readiness for exactly this ordering; this source now does the same. Also record the identity collaborator in the two module headers that gained the dependency without documenting it, and scope the `builtin_product_skills` docs to the engine that reads it, matching the note the identity section already carries. * fix(agent-core-v2): apply the product-skill switch to session-less listings `builtin_product_skills = false` only reached the scoped skill source. The SDK's `listWorkspaceSkills` and the server's `GET /workspaces/{id}/skills` both composed the raw `BUILTIN_SKILLS` constant, and the web app feeds its pre-session onboarding menu from that route — so the five product skills stayed listed until a session existed, then vanished from the session's catalog. Move the decision into `visibleBuiltinSkills(enabled)` next to the constant and route every consumer through it, reading the switch via the shared `builtinProductSkillsEnabled`. Keeping "what counts as a product skill" in one place is the point: three copies of the predicate would drift the next time a builtin is added. The SDK listing also awaits config readiness, which it did not do before. * fix(node-sdk): await config before materializing the global MCP OAuth provider `McpOAuthService` caches providers by store key and stamps the client name when it first builds one, and the preceding `globalMcpConfig.get()` reads `mcp.json` directly rather than through `IConfigService`. So a `beginGlobalMcpServerAuth` call made right after the harness is created could resolve the identity before config finished loading, pinning the built-in label for the rest of the process — including the OAuth dynamic registration a third-party MCP server records. `testGlobalMcpServer` already awaited config readiness for its own reasons; this path now does too. * refactor(agent-core-v2): drop the unused builtin-skill registrar `registerBuiltinSkills` stamped the raw constant into a catalog for "edge composition without a Session" — exactly the shape that now has to respect `builtin_product_skills`. It has no callers in v2 and is not exported from the package index, so it was dead code that also stood as an invitation to bypass the switch. v1 keeps its own copy. Every remaining path composes builtins through `visibleBuiltinSkills`. * fix(agent-core-v2): send the configured identity on custom-registry imports `:import_registry` fetched a user-supplied third-party URL with a hardcoded `kimi-code-kap-server` User-Agent, so the first request to a registry announced the product while every scheduled refresh of the same registry announced the configured identity. The hardcoded value was wrong on its own terms too: that token names the server, and this path also runs in the CLI. Both services now project the identity through `identityUserAgent`, which carries the two guards (no host header, or no identity) once instead of per caller. The model catalog keeps an inline copy on purpose — kosong is a foundational layer and must not import an app domain. Sweeping the remaining outbound User-Agent sources found no further gaps: WebFetch deliberately sends a Chrome-like UA, the models.dev catalog fetch sends none from the CLI, and kap-server's `user-agent` reads are inbound. * docs: scope the identity env vars and condense the changeset The environment-variable reference advertised all three new variables without noting that only the agent-core-v2 engine reads them; the configuration page already carried that note. Added in both locales. The changeset had grown into two paragraphs of implementation detail, which is what would land in the CLI release changelog. `gen-changesets` asks for one short sentence plus at most a one-line usage hint. * docs(agent-core-v2): describe the identity as what the agent calls itself The module headers had drifted into describing the feature by what it keeps off the wire rather than what it configures. Reworded so they state the capability: the identity is the name the agent uses for itself, and the unset case is a no-op rather than something "safe". The product-skill switch excludes skills rather than hiding them. Wording only; behavior and structure unchanged. * test(agent-core-v2): cover the identity on custom-registry imports The import path switched from a hardcoded `kimi-code-kap-server` token to the host User-Agent projected through the identity, but nothing asserted it. Two cases pin both halves: a configured identity reaches the request, and an unconfigured one leaves the host header intact — the second matters because a single case would also pass if one hardcoded value had simply replaced another. Both fail against the previous implementation. * fix(node-sdk): guard every global MCP OAuth path behind config readiness `McpOAuthService` caches providers by store key and stamps the client name when it first builds one, so any path that can materialize a provider has to run after config has loaded. `beginGlobalMcpServerAuth` awaited readiness, but `resetGlobalMcpServerAuth` reaches the same cache through `invalidate()` -> `getProvider()` without waiting: resetting auth right after the harness is constructed pinned the built-in client name, and the await added to the begin path could not help because it then reused that cached provider. Rather than add the missing await, the accessor is now async and holds the guard itself, so the service cannot be obtained before config is ready and a future entry point cannot forget. The remaining `configReady` in `testGlobalMcpServer` stays — that one is for its own `[mcp]` section read. * fix(agent-core-v2): send the configured identity on models.dev requests The directory fetch behind `listModelsDevProviders` / `getModelsDevProvider` still hardcoded a `kimi-code-kap-server` User-Agent, so browsing or importing from models.dev announced the built-in product — and claimed to be the server even when running in the CLI. Only the custom-registry import had been fixed. `getModelsDevCatalog` now takes the User-Agent from its caller: the module is plain module-level state with no container access, and the value depends on the host and the configured identity, which only the calling service can see. All four third-party fetches in that service share one helper. Where the host states no User-Agent, a neutral token stands in rather than dropping the header — these are directories the service chooses to call, so there is no host intent to preserve, unlike the provider requests the model catalog assembles. Both new tests fail against the previous hardcoded value. * test(agent-core-v2): assert the product-skill set literally The expected sets were derived from the same `productSpecific` field the production filter reads, so a builtin silently losing its marker would just move between sets and leave every assertion green — while staying visible to the model once the switch is off. The five names are now literal, with a test asserting the marked set matches them exactly. Dropping the marker from one skill now fails four tests instead of none. Also states the App scope in the identity contract header, per the domain's comment convention for contract files. * fix(agent-core-v2): normalize the host-declared display name too Blank and padded values were normalized on the config side but not on the host fallback, so an embedding host passing `displayName: " "` rendered "You are ," into the system prompt, and a padded name kept its padding. Same rule now applies to every source of the name. Also names `agentIdentity` as the collaborator in the request-headers adapter header, which described the value it obtains without saying which domain resolves it. The three new cases fail against the previous implementation. * fix(agent-core-v2): keep the configured slug when the host sends no User-Agent The neutral fallback added for hosts that state no `User-Agent` discarded a configured identity along with it: `identityUserAgent` returns `undefined` as soon as there is no host header to rewrite, so `?? DEFAULT_IDENTITY_SLUG` sent the literal `agent` even when `[identity].slug` was set — precisely the case that fallback exists to serve. The configured slug now stands on its own, with the neutral token reserved for having neither. The four combinations of (host header, configured slug) had three tests; the missing one is the one that was wrong. It now fails without this change. `outboundUserAgent` also awaits config readiness before reading the identity, so a browse issued right after bootstrap cannot send the pre-load value — the guard lives in the accessor rather than at its four call sites, matching how the same race is handled elsewhere in this branch. Both headers here and in `discoveryService` now name `agentIdentity` as the collaborator resolving that token. * test(acp-server): follow the renamed skill-activation tag `acp-server` arrived on main after the tag rename, so its two assertions still expected `kimi-skill-loaded` and failed once the branches met. Also updates the web app's CSS comment, which named the old tag from the start of this branch — a comment, so nothing ever failed on it. Found by CI: the merge verification only ran agent-core-v2's suite, and this package is neither a dependency nor a dependent of it. * fix(agent-core-v2): present the configured slug on registry refreshes too The previous round taught the import path to fall back to the configured slug when the host states no `User-Agent`, but left the scheduled refresh of the same registry on the bare projection — so one registry could see `acme` on import and the runtime default on refresh. Extracting `identityUserAgent` had made the two paths share a function without sharing the policy. The choice itself is now the shared piece: `identityUserAgentOrDefault` always yields a value, for the directories this process chooses to call, while `identityUserAgent` stays the form that rewrites only what the host already sends — what a provider request needs, where the host's silence is its own choice. * docs(agent-core-v2): move new member docs into the module headers The domain's comment convention is absolute — comments live solely in the top-of-file block — and I had read the "functions, methods, or statements" clause as leaving interface members out. It does not: only 25 of 734 v2 sources carry an indented block, so the members I documented were the exception, not the pattern. Seven members across six files move into their headers. `types.ts` had no header at all, so it gains one. * fix(agent-core-v2): connect session MCP overlays after config is ready The shared manager reaches `connectAll` through `initialize()`, which awaits the config domain first; `sessionOverlay` called it straight away. A session carrying ephemeral `mcpServers` created right after bootstrap therefore resolved the client name before config had loaded and initialized under the built-in one. The blast radius is wider than that one connection: a remote server sends the overlay through `hasTokens()`, which materializes an OAuth provider on the *shared* service and caches it by store key — so the early name outlives the connection that raced. The overlay now connects behind `mcpConfig.ready`, leaving the returned readiness promise unchanged. * fix(agent-core-v2): reload builtin skills when their switch changes The workspace catalog keeps each source's contribution for the life of the handler, so a `builtin_product_skills` toggle never reached an existing handler's sessions. That was harmless while every surface read the same constant — but routing the session-less listings through the config made the two views disagree, since those read the switch on every call. Follows `ExtraFileSkillSource`: subscribe to the owning section and fire `onDidChange`, which the catalog already turns into a source reload. The test asserts an unrelated section does not trigger it. * fix(agent-core-v2): apply the identity to self-configured web services `[services.moonshot_search]` and `[services.moonshot_fetch]` name their own `base_url`, so both services can point at an endpoint the user chose — but each forwarded the host request headers verbatim, sending the built-in product token there under a configured identity. Only the services-config path is rewritten; the managed OAuth path keeps the host headers as they are, being the endpoint the session authenticated against. The distinction is the same one the model catalog draws per vendor. `identityHeaders` carries the rewrite across a whole header set, so this is the fourth caller sharing the projection rather than repeating its guards. A pair of tests pins both halves. My earlier sweep classified these two as official by their names instead of asking who chooses the URL, which is why they were missed. The contract header is also condensed here, per the convention below. * docs(agent-core-v2): condense the identity headers to their contracts The comment convention is one sentence with two halves — comments live only in the top-of-file block, *and* that block states the module's role without narrating implementation. Moving the member docs up last round satisfied the first and broke the second: the headers ended up spelling out the slug folding algorithm, the strip mechanics, and the load order. Kept what a caller or the next editor would get wrong without it (why the value is read rather than snapshotted, what `undefined` obliges a consumer to do, why this source waits for config). Dropped what the code already says. 22/12/12/13 lines, against 53 in `catalogService.ts` — length was never the problem. * fix(agent-core-v2): rebuild active prompts when the builtin skills change Reloading the catalog on a `builtin_product_skills` toggle left existing agents holding the old listing: `AgentProfileService` refreshes the prompt only for the plugin source, so a disabled switch kept advertising skills that were gone, and enabling it left them missing until an unrelated refresh. The plugin source is special because it also contributes prompt sections (#2314), and the file-backed sources are left out for cost — their fs watches would rebuild every agent's prompt on each edit. The builtin source has no watch: it changes only when its config switch is toggled, so it belongs with the plugin source rather than with the file ones. Subscribing to the catalog rather than the config section is load-bearing. The catalog fires after the contribution is replaced, whereas a config subscription would race the reload, and `resolveSkillListing` only awaits the catalog's *initial* readiness — so the rebuilt prompt could read the listing it was meant to replace. The source id is a named constant now, so the subscription does not match on a bare string. * refactor(agent-core-v2): freeze the agent identity for the process lifetime The identity is announced outward (MCP initialize, OAuth registration, provider request logs) and cannot be re-announced, so mid-process changes could only ever apply partially. Resolve it once when config first loads and hold it for the life of the process: IAgentIdentity now hands out a frozen snapshot via resolved()/current(), carrying finished products (outbound User-Agent variants, rewritten header set) so call sites stop composing host headers with the slug themselves. The kosong host-headers port carries two finished layers and the catalog only picks one; consumers gain no invalidation obligations because the value can never change after the freeze. [identity] edits take effect on the next start (documented). * fix(agent-core-v2): locate the User-Agent header case-insensitively HTTP header names are case-insensitive, but the snapshot builder looked up 'User-Agent' by exact key: an embedding host spelling it 'user-agent' got no third-party UA and kept its own product token on the services path even with an identity configured. The builder now locates every case variant and rewrites each in place, keeping the host's spelling. Also corrects the two web-service headers that still described both paths as sending the bootstrap headers, naming agentIdentity as the collaborator behind the config path, and documents that a resumed session keeps its recorded system prompt. * fix(agent-core-v2): attribute header provenance from the finished third-party layer Inspection reconstructed the non-full host layer from the raw headers with an exact-case 'User-Agent' lookup, so a host spelling the header 'user-agent' got a resolved User-Agent with no provenance entry even though the runtime sends the rewritten value. buildModel now captures the port's finished third-party layer in the trace and attribution reads it, keeping inspect() on the same resolution pass as get(). Also condenses the identity contract header to its external role, and documents that an existing MCP OAuth authorization keeps the client registration it was granted under (reset the server's auth to register under the new identity). * fix(agent-core-v2): keep web tool backends from racing the identity freeze An env-configured [services] endpoint is visible before config finishes loading, and FetchURLTool / WebSearchTool materialized their backends at construction — so a fast bootstrap could hit the identity snapshot's pre-freeze guard during agent creation, and the composed backend pinned config and login state for the agent's lifetime against the service's documented per-call resolution. Both tools now resolve their backend per invocation, the WebSearch activation gate checks presence alone through the new hasWebSearchProvider() (no provider composition, no identity read), and bind() awaits the identity freeze before materializing the model, whose resolution reads the identity through the host-headers port.	2026-08-04 22:35:15 +08:00
qer	0abcd00f7f	feat(cli): add built-in Computer Use and WebBridge capabilities (#2407) ... * feat(agent-core-v2): add built-in capabilities (kimi-cu, kimi-webbridge) with REST routes Add a capability domain holding a closed registry of built-in product capabilities. Each entry owns layered readiness detection and idempotent install orchestration: binary runtimes from fixed official CDN URLs (KimiCU.app + launchd service + TCC permission state; the WebBridge daemon with start-if-down semantics for Kimi Work coexistence) plus agent wiring through the plugin service. The WebBridge wiring un-shadows stale user-source skill copies (user priority beats plugin priority). kap-server exposes the domain as GET /api/v1/capabilities, GET /api/v1/capabilities/{id}, and POST /api/v1/capabilities/{id}:install with client-polled progress and new wire codes 40418 / 40922 / 40923. The plugin marketplace gains an official kimi-webbridge entry (browser-control skills) packaged by the existing CDN build. * fix(agent-core-v2): rename the webbridge wiring plugin to kimi-webbridge-skill An official kimi-webbridge guide plugin (install/remove setup skills, v3.0.4) already exists at the marketplace path the capability installer pointed at — a different artifact owned by another release line. Give the browser-control usage-skill plugin its own id/path instead of colliding with (or overwriting) the guide plugin. The capability entry's detect/install now tracks kimi-webbridge-skill; a machine with only the guide plugin correctly reports the skill layer as missing. * feat(agent-core-v2): shelf installs auto-complete capability binary layers Two changes to make the plugin marketplace a first-class install path: - Marketplace gains kimi-cu (sourced from the CU team's CDN zip — no repackaging) and the kimi-webbridge usage-skill plugin now claims the kimi-webbridge id at v4.0.0, deliberately superseding the WebBridge guide plugin (v3.0.4, install/remove guide skills): guide users get a version upgrade onto the real usage skill. - The capability service subscribes to IPluginService.onDidReload: when a capability's wiring step flips to ok through ANY install path (shelf, TUI, CLI), it auto-completes the missing binary layers (KimiCU.app + service, or the WebBridge daemon). Triggers only on the false→true edge so completed installs with still-missing manual steps (TCC permissions) never retrigger heavy downloads on later reloads. * fix(plugins): keep kimi-webbridge plugin version aligned with the upstream skill The plugin version tracks the bundled official usage skill (1.11.3) so version drift against the WebBridge release line stays visible, instead of minting an independent 4.0.0. * fix(agent-core-v2): never report the webbridge installer-script version as the product version The on-disk ~/.kimi-webbridge/bin/kimi-webbridge.version file tracks the installer's own lineage (3.1.x, bumps on every install/upgrade run), not the product version (v1.11.3 — daemon, extension, and skills all share it). A downed daemon would have shown the misleading installer number; report no version instead (live /status remains the source of truth). * chore(plugins): list kimi-cu on the marketplace without a pinned version Marketplace versions are optional by schema: rows display the version detected from the installed plugin's manifest, and update prompts only fire on a valid semver latest > local comparison. A hand-maintained number would drift just like the guide plugin's did. The locally built kimi-webbridge entry keeps its manifest-stamped version (1.11.3). * fix(agent-core-v2): fire onDidReload on plugin mutations, not just explicit reload installPlugin / setPluginEnabled / removePlugin changed the catalog silently — consumers listening to onDidReload (session skill-catalog convergence, the capability shelf-install hook) only converged on an explicit reloadPlugins(). Fire the same summary-shaped event on every mutation (added:[id] / [] / removed:[id]) so every install path converges. This also unbreaks the shelf-install hook on real hosts: its unit tests passed against a fake emitter that fired on installs, which the real service never did. * feat(kap-server): add plugin management and marketplace REST routes Expose the App-scope plugin service over the wire so non-CLI hosts (desktop, web) can manage plugins end to end: - GET /api/v1/plugins/marketplace — catalog (pluginMarketplaceUrl server option / KIMI_CODE_PLUGIN_MARKETPLACE_URL env / production default) merged on demand with live install state; updateAvailable only on strict semver catalog > installed (no semver dependency) - GET /api/v1/plugins, POST /api/v1/plugins {source} - POST /api/v1/plugins/{id}:{enable,disable,remove} - New wire code 40419 plugin.not_found Mutations flow through IPluginService, so they serialize with other install paths and fire onDidReload (session skill catalogs and the capability shelf-install hook converge). * feat(agent-core-v2): surface a machine-key note from capability installs CapabilityEntry.install now resolves an optional note exposed through CapabilityInstallProgress.note (wire-visible). The webbridge entry returns 'user-skill-migrated' when it replaces a pre-existing user-source skill (from the official installer) with the plugin-managed copy — clients can localize the migration instead of the skill silently disappearing from the user's directory. * feat(tui): let the real WebBridge marketplace entry win over the pinned promo The hardcoded Web Bridge row was built when WebBridge had no plugin package — it pinned above the Official tab and shadowed any catalog entry with the same id (open-in-browser only). Now that the marketplace carries the real kimi-webbridge plugin, flip the precedence: the catalog entry renders and installs normally, and the pinned promo becomes a loading/error/legacy-catalog fallback only. Footer counts keep their old semantics (catalog-only; the promo row is never counted). * fix(tui): dim the installed state so it stops reading as the install action Both badges shared a near-identical green-ish treatment in the same column, making a quiet fact look like a clickable action. States now recede (installed → textDim) while actions stay loud (install → primary, update → warning). * feat(agent-core-v2): converge plugin state across processes sharing a home Multiple hosts share one KIMI_CODE_HOME (CLI, desktop, other agents), but each PluginService kept a private in-memory snapshot: a plugin installed or removed in one process stayed invisible to every other live process until its next restart — new sessions there kept offering stale plugin skills/MCP, and the capability shelf hook never saw peer installs. Watch <home>/plugins for installed.json changes and reloadPlugins (debounced, echo-suppressed around our own mutations) so all consumers converge in well under a second: session skill catalogs, plugin MCP mounts, and the capability shelf-install hook alike. * fix(agent-core-v2): un-shadow webbridge user skills in BOTH user dirs kimi-code resolves user-scope skills from two roots (~/.kimi-code/skills and ~/.agents/skills), both at priority 20 — a stale copy in either shadows the plugin-managed wiring (priority 5), and also keeps the capability working after the plugin is removed, which reads as 'uninstall did nothing'. Migrate copies in both dirs during install; other runtimes' dirs (~/.claude, ~/.codex) remain untouched. * feat(tui): show live runtime-setup progress for capability installs Installing a capability plugin (kimi-cu, kimi-webbridge) from the /plugins shelf kicked off a silent background binary install — the row flipped to installed while megabytes of runtime downloaded invisibly. Route capability entries through the capability surface instead: the panel's inline installing line now mirrors live progress (step + percent) until the install settles, and the transcript reports ready / failure-with-retry / still-running accordingly. Capability removal prints an explicit note that runtime binaries are deliberately left untouched (the capability keeps working), since that read as 'uninstall did nothing'. Plumbs the capability service through klient's global facade ('capabilityService' decorator resolves in-process) and the node-sdk v2 client; Session exposes it with a structural feature-detect so v1 engines fail clearly. * docs(plugins): keep the kimi-cu marketplace blurb accurate for every client Only the capability-aware clients auto-install the KimiCU.app runtime; older builds still get wiring-only (the wrapper's error message then points at the official setup script). Don't overpromise in the catalog text every version reads. * feat(agent-core-v2): install capability wiring from client-bundled plugin copies The kimi-cu / kimi-webbridge wiring plugins ship inside the client release instead of the marketplace catalog, binding their visibility to the client version. Capability installs now resolve the bundled copy (env override, then npm-layout and source-checkout probes from the module) and install it as a local path, replacing the two CDN zip URLs. A missing bundle fails the wiring step with a clear reinstall-or-upgrade message. * build(cli): bundle the capability wiring plugins into client releases Vendor the official kimi-cu plugin (v0.5.4, from the CU team's plugin zip) next to kimi-webbridge under plugins/official, copy both into apps/kimi-code/bundled-plugins at build time, and ship them in the npm package (files) and the native SEA blob (a new bundled-plugins asset set extracted into the native cache at startup, published to the engine via KIMI_CODE_BUNDLED_PLUGINS_DIR). Desktop points the same variable at its extraResources copy. The .gitignore build-output entries are anchored so sources under src/native and test/native stop being silently ignored. * revert(plugins): remove the kimi-cu and kimi-webbridge marketplace entries Both capabilities now distribute with the client (bundled wiring), so the catalog drops back to kimi-datasource / superpowers / vercel-plugin. Older clients never see the entries; current clients install from the Built-in section. This also reverts the marketplace blurb commit 0635e99c5. * feat(tui): add a Built-in capabilities section to the plugins panel The Official tab now opens with a Built-in section fed by the engine's capability registry (kimi-cu / kimi-webbridge): per-row install state (install / finish setup / ready), Enter runs the full capability install with live progress, and unsupported rows hide (kimi-cu off macOS). The WebBridge promo fallback only remains for v1 engines — on v2 the real built-in entry wins. Rows double as the reinstall path: a client upgrade ships newer wiring, and installing again upserts from the new bundle. * docs(plugins): document the Built-in section and refresh the capability changeset * build(nix): stage bundled capability plugins into the SEA build The native SEA blob now embeds the bundled-plugins asset set, so the nix derivation needs the plugins tree in its src fileset and the staging step alongside copy-web-assets before build:native:sea. * revert: drop the client-bundled wiring distribution Built-in visibility is simpler to get by injecting the two capability entries into the marketplace catalog at load time; the wiring plugins themselves keep installing from their fixed official CDN zips. Removes the vendored kimi-cu plugin, the bundled-plugins npm/SEA packaging and flake staging, the engine bundle resolver, and the plugins panel's Built-in section. Keeps the /agents/ and /native/ gitignore anchors so sources under src/native and test/native are not silently ignored. * feat(cli): inject the built-in capability entries into the marketplace catalog The kimi-cu / kimi-webbridge entries are appended by the client at catalog load time instead of being served by the remote marketplace.json, binding their visibility to the client version (older clients never see them). No version is pinned — reinstalling upserts the wiring — and ids the catalog already carries always win. In a source checkout the webbridge entry installs the repo's own plugin copy; packaged builds use the official CDN zip. This reverts the docs paragraph about the Built-in section, which the simpler approach makes unnecessary. * test(tui): select the catalog's own first row in marketplace install tests The client-injected capability entries suppress the WebBridge promo and append after the catalog rows, so Kimi Datasource now leads the Official tab — the extra down-key landed on kimi-cu instead. * feat(cli): surface the built-in capabilities as client-injected marketplace entries The kimi-cu / kimi-webbridge entries are injected into the marketplace catalog by the client (v2 engine, default catalog only) instead of being served remotely, binding their visibility to the client version; injected rows mask same-id catalog rows, so what these ids mean stays decided by the client release — a future official listing only reaches older clients, whose fix is to upgrade. The /plugins panel shows capability readiness on the rows (setup incomplete / installing…), platform-gates kimi-cu to macOS, and Enter finishes the runtime setup with live progress; v1 keeps the plain plugin install path and the WebBridge promo fallback. Capability and plugin calls move from the ad-hoc REST routes onto the typed klient contract (capabilityService next to pluginService), so the public REST surface returns to its pre-feature shape. Detection is presence-only — version pins removed: the current version is always read live (Info.plist, daemon status, install records), installs are detect-first and idempotent so an interrupted setup can be retried, and reinstalling pulls the latest managed artifacts (the passive upgrade path). * ci: retrigger checks * fix(cli): recognize Computer Use CDN plugins as official * fix(cli): keep built-in entries on catalog outage and isolate detector failures Two review follow-ups: the client-injected entries no longer disappear when the marketplace catalog is unreachable (they are not served by it), and a single capability's failing detect probe degrades to a failed step on that entry instead of rejecting the whole listCapabilities call. * refactor(cli): simplify built-in capability integration * refactor(cli): source built-in catalog rows from the engine and tighten detect probes The injected marketplace entries are now derived from the engine's capability registry (listCapabilities) instead of hardcoded client-side copies — the util only owns the mask/append mechanics, and capability ids are no longer pinned in the CLI (the remove note resolves them through the registry too). kimi-cu's detect-path probes (service-status, xpc-ping) get a 3s timeout — they answer in milliseconds when healthy but run on every status listing, so a wedged binary must degrade quickly instead of stalling the panel. Document the Official tab's built-in capability rows in the plugins guide. * fix(cli): answer capability id membership without running detectors listCapabilities() runs every entry's detect probes (seconds on a wedged binary), so using it to decide whether to print the post-remove hint made every plugin removal pay a full detection round. The id set is part of the client/engine contract (mirrored in the klient schema), not product data that drifts — restore the closed-set check. The injected catalog rows keep flowing from the registry. * fix(agent-core-v2): make capability setup recover from disabled, partial, and wedged states Three review follow-ups on the install path: setup now re-enables the wiring plugin when a previous disable survived installPlugin's upsert (detection requires enabled, so it would otherwise strand the capability at partial); the webbridge daemon-binary step verifies the executable bit on POSIX, so an install interrupted between rename and chmod re-downloads instead of failing start with EACCES; and kimi-cu's detect degrades wedged CLI probes (service-status, xpc-ping) to failed steps instead of throwing, keeping the detect-first install able to repair the remaining layers — with the probe timeout injectable for tests. * fix(agent-core-v2): abort capability downloads whose byte stream stalls downloadToFile had no inactivity deadline: a CDN connection that stops producing bytes hung the background install forever, wedging the capability in a permanent installing state (retries rejected as in-progress) until the process restarted. An idle watchdog now fails the download after 30s without a chunk; slow but flowing downloads are unaffected. * fix(tui): stop offering capability setup on unsupported platforms An installed wiring plugin whose capability is unsupported on this OS/arch (kimi-cu off macOS, webbridge on an unknown arch) was treated like a partial setup: the Installed tab showed setup incomplete and Enter routed to installCapability, which the service always rejects. Setup actions are now gated to actionable states (not_installed / partial); unsupported renders as a dim fact and Enter opens details. * fix(agent-core-v2): cover the two remaining install wedge modes Review follow-ups: the KimiCU app step now requires an executable binary, so a ditto interrupted mid-copy reads as missing and the next setup re-copies instead of failing EACCES forever; and downloadToFile's idle budget now also covers the response-header phase via an AbortSignal on the fetch itself, so a connection that never completes headers fails the install (clearing the running state) instead of hanging it. * fix(tui): render capability rows independently of the catalog fetch While the marketplace catalog was loading or unreachable, the Official tab showed only the pinned WebBridge promo — built-in runtime setup was blocked by an unrelated remote fetch, and Enter opened the browser instead of installing. Locally-known capability rows (from the engine registry) now render and install in every catalog state; the promo remains only as the v1 fallback. * fix(agent-core-v2): keep KimiCU cleanup timeouts best-effort stopOldProcesses is documented as || true, but runCommand propagates timeouts: a wedged old binary made kimi-cu uninstall exceed the command timeout and the reinstall died before ditto could replace the app. Cleanup commands now swallow failures (the timeout already attempts a kill) so the replacement always proceeds; the command timeout is injectable for tests alongside the probe timeout. * fix(cli): inject built-in entries only for the default marketplace catalog Injection is part of the default catalog experience: any explicit replacement (slash-command source or KIMI_CODE_PLUGIN_MARKETPLACE_URL) now opts out wholesale — its same-id rows are never masked by the built-ins, and an unreachable custom catalog surfaces its own failure instead of being silently replaced by a built-in-only tab. * refactor: align capability row rendering on the source marker and drop conditional spreads Marketplace-row capability enrichment (status, badges, issue details, platform filtering) now keys on the capability:<id> source marker — the same condition Enter uses to route installs — so a custom catalog row that merely reuses a built-in id renders and installs as a plain plugin. Also replaces the conditional-spread optional fields with direct undefined-valued assignments per the repo coding rules. * refactor(agent-core-v2): move capability comments to the file headers The domain's comment convention allows only the top-of-file block: responsibility and scope context for the recent hardening (detect-first idempotent install, executability gates, probe-failure degradation, best-effort cleanup, download watchdog, per-entry detection isolation) now lives in the module headers, and inline narration beside statements and members is removed. * fix(tui): follow an in-progress capability install instead of restarting it Opening /plugins while a capability setup is already running showed the installing… row, but Enter called installCapability again and the service's duplicate-start rejection (40922) surfaced as a fake failure. The panel now checks the live status first and, when an install is already running, skips the start call and just polls for the existing progress. * fix: align two more replacement paths with their contracts The EXDEV daemon-binary fallback now stages on the target filesystem and atomically renames over the destination instead of opening a possibly-running binary for write (ETXTBSY on Linux). And the panel's fallback capability rows (catalog loading/error) now follow the same default-catalog condition as the loader injection, so an explicitly overridden marketplace fully replaces the Official tab. * fix(tui): make the built-in row marker unforgeable The capability:<id> source string was the trust signal for routing rows into capability installs, but any catalog can write that string — a custom marketplace could smuggle a row past the third-party trust path into an official runtime install. Injected rows now carry an internal builtIn flag that the field-by-field catalog parser never produces; rendering and install routing key on the flag, and the source string is purely diagnostic. * fix(agent-core-v2): include MCP server enablement in capability readiness A user who disabled the kimi-cu stdio MCP server (/plugins mcp disable) got a ready capability with no Computer Use tools in new sessions: the plugin step only checked the plugin toggle, and installPlugin's upsert preserves per-server state. Readiness now requires every declared MCP server enabled (reporting e.g. mcp 0/1 enabled), and setup re-enables disabled servers alongside the plugin toggle. * fix(agent-core-v2): shell-quote ditto paths in the elevated KimiCU copy The elevated fallback escaped paths only for the AppleScript string delimiters, not for the /bin/sh command line inside do shell script: a TMPDIR with spaces broke the install, and shell metacharacters in the temp path could inject commands into an administrator-privileged script. Paths are now POSIX single-quoted first, then the assembled command is AppleScript-escaped. * fix(agent-core-v2): never break a working KimiCU on a failed update The reinstall stopped and uninstalled the old service before the downloaded archive was unpacked: a corrupt or captive-portal zip then tore down a previously ready setup. The archive is now staged and unpacked first, and the app step additionally requires the bundle's Info.plist, so a partially copied bundle reads as missing and gets re-copied instead of failing registration against a corrupt bundle. * fix(agent-core-v2): limit the fetch deadline to the header phase The 30s AbortSignal stayed attached for the whole request, so a slow-but-healthy download of a large archive was aborted at 30s total even while chunks kept arriving — exactly what the per-chunk idle watchdog was meant to allow. The header phase now uses an AbortController cleared once headers arrive; the body remains governed by the inactivity watchdog alone. * test(tui): provide the harness plugin facade in the capability command fakes The lazy-session refactor routes session-less plugin calls through host.harness; the fake host now mirrors that shape.	2026-08-04 17:59:16 +08:00
qer	da6646bf57	docs(changelog): fix 0.32.0 entry formatting and doc links (#2598)	2026-08-04 17:02:08 +08:00
qer	85e4cf0346	docs(changelog): shorten the 0.32.0 loop_control and token_counting entries (#2595) ... * docs(changelog): shorten the 0.32.0 loop_control and token_counting entries * docs(changelog): tighten the 0.32.0 loop_control and token_counting entries further * docs(changelog): reword 0.32.0 Polish entries from the user perspective	2026-08-04 16:41:59 +08:00
qer	c2e53aef6c	docs: polish the 0.32.0 changelog and fill 0.32.0 doc gaps (#2594) ... * docs: polish the 0.32.0 changelog and fill 0.32.0 doc gaps * docs(changelog): note SessionEnd archive and KIMI_TOKEN_COUNTING_STRATEGY for 0.32.0 * docs(changelog): move the 0.32.0 token_counting entry from Features to Polish	2026-08-04 16:31:25 +08:00
7Sageer	54c04bf03d	feat: /fork no longer switches to the forked session (#2565) ... * feat: /fork no longer switches to the forked session Forking used to switch to the new session, which closed the source session and force-stopped its background tasks (and canceled any in-flight turn). /fork now creates the copy and stays in the current session; the fork can be opened explicitly via /sessions. * fix(tui): release fork runtime when staying current	2026-08-04 15:24:12 +08:00
Haozhe	21185447fe	feat(agent-core-v2): add tokenCounting service with strategy config and measured anchors (#2563) ... * feat(agent-core-v2): add tokenCounting service with strategy config and measured anchors - add IAgentTokenCountingService as the single owner of token counts: context size, full-request size, and estimate primitives, replacing the scattered contextSize/tokenEstimate/fullCompaction paths - add [token_counting] config section with strategy = measured+estimated (default) / measured / estimated, plus the KIMI_TOKEN_COUNTING_STRATEGY env override; measured zeroes all estimates, estimated ignores anchors - keep a live measured-anchor ledger in TokenCountingModel: each LLM exchange writes a real anchor, undo truncates the ledger so the surviving prefix restores its REAL measured size instead of a re-estimate, and compaction rebases to a single anchor that blends the compaction exchange's measured summary output tokens - skip writing an anchor when the stream reports no usage event instead of anchoring emptyUsage() zeros, which zeroed the context size and silenced compaction for providers without usage reporting - return the strategy-resolved size (not measured) from rpc getContext so the tokenCount contract stays correct under the estimated strategy - migrate all consumers (contextMemory, fullCompaction, llmRequester, rpc, mirrorAgentRun, sessionLegacy, kap-server legacyStatus, node-sdk, kimi-inspect) to the new service; edge bridges no longer read the wire model directly - document [token_counting] and KIMI_TOKEN_COUNTING_STRATEGY in the bilingual config reference * fix(kap-server): omit maxContextTokens instead of pushing 0 when unknown - readLegacyStatus falls back to the default model's context limit when no model is bound, and omits maxContextTokens entirely when the limit is unknown (0 is the engine's UNKNOWN_CAPABILITY marker, not a real limit) - profileService no longer emits maxContextTokens in agent.status.updated when the bound model alias does not resolve * fix(agent-core-v2): resolve token_counting strategy only at the reporting edge - keep measured anchors and heuristic estimates both recorded and feeding internal logic (compaction triggers, budgets, overflow backoff) regardless of the configured strategy - add IAgentTokenCountingService.statusSize() as the single strategy-resolved outward reading and route the WS/REST/RPC status surfaces through it - fix the context-size display falling back to provider-reported usage under the estimated strategy - fix compaction overflow backoff retrying identical messages until failure under the measured strategy (the strategy-gated estimator read as 0)	2026-08-04 09:44:21 +08:00
Haozhe	6ba75a173b	feat(config): add deprecation mechanism and rename loop retry limit (#2572) ... * feat(config): add deprecation mechanism and rename loop retry limit - agent-core-v2 config: declarative section `deprecations` (deprecated TOML keys are ignored and report a warning diagnostic; the file is never rewritten) and env binding `deprecatedEnv` (old var still resolves as a fallback with a warning), surfaced via the new `IConfigService.onDidChangeDiagnostics` event - loop_control: rename `max_retries_per_step` to `max_attempts_per_step` and `KIMI_LOOP_MAX_RETRIES_PER_STEP` to `KIMI_LOOP_MAX_ATTEMPTS_PER_STEP`; `max_steps_per_run` moves onto the same mechanism (no longer silently mapped) - kap-server: push the global `event.config.warning` WS event to every connection whenever the config warning set changes - TUI: show config diagnostics in warning yellow at startup instead of the dim startup notice - docs: config-files/env-vars (en+zh), regenerated config manifest, and the agent-core-dev config guide * feat(cli): validate config.toml against v2 section registry in doctor - add v2/validate-config.ts: validate config.toml with the agent-core-v2 ConfigRegistry, reporting registered-section schema failures as errors and unknown top-level keys / deprecated keys and env vars as non-fatal warnings - route `kimi doctor` config validation through the v2 validator when the KIMI_CODE_EXPERIMENTAL_FLAG master switch is on (lazy dynamic import, keeping the v2 module graph off the default path) - let doctor checks surface non-fatal warning messages on OK results * chore: downgrade loop-control changeset to patch	2026-08-03 20:17:01 +08:00
7Sageer	29c9e2ab20	docs: clarify secondary model default binding and override precedence (#2553) ... The secondary_model section did not state whether spawned subagents are forced onto the secondary model or only default to it, nor the full override precedence. Make the semantics explicit in both locales: - spawning resolves the model in order: explicit tool-call model -> profile model_preference -> configured secondary model (default) - the tool's model parameter accepts only "primary" / "secondary" - "primary" means the model the main agent is currently running, not necessarily default_model - the user has no per-spawn switch; overriding is the main agent's decision or a profile setting Also unify secondary-model terminology and the [models] alias wording across the config-files, agents, slash-commands, and env-vars pages.	2026-08-03 15:42:09 +08:00
qer	7648874730	docs(changelog): sync 0.31.1 from apps/kimi-code/CHANGELOG.md (#2470)	2026-07-31 20:21:53 +08:00
liruifengv	d8f455d694	docs(changelog): sync 0.31.0 from apps/kimi-code/CHANGELOG.md (#2404) ... * docs(changelog): sync 0.31.0 from apps/kimi-code/CHANGELOG.md * docs(changelog): polish 0.31.0 entries and note secondary model as experimental	2026-07-30 15:39:17 +08:00
Kai	691ec4679e	fix: remove the blocking wait from the TaskOutput tool (#2379) ... * fix: remove the blocking wait from the TaskOutput tool The block/timeout parameters let a model stall the whole turn waiting for a background task (up to 3600s), even though completion already arrives via automatic notification. Remove both parameters from the v1 and v2 engines (kept in model-facing parity), simplify retrieval_status to success/not_ready, and update the tool, Bash, and Agent prompt wording plus user docs accordingly. Stale callers passing block are silently treated as a non-blocking snapshot. * fix: align background-task prompts with the non-blocking TaskOutput The compaction reminder promised TaskOutput could fetch a task's result for tasks that are still running, where it now returns not_ready — reword it to snapshot semantics and point at the completion notification. Also list AskUserQuestion(background=true) as a task source in the TaskOutput description. * test: exercise stale TaskOutput args through the runtime validator A stale block/timeout argument never reaches the tool: the executor's preflight validates args against the closed tool schema and rejects them immediately, so the old test documented silent-tolerance semantics the runtime never exhibits. Assert the real behavior through compileToolArgsValidator/validateToolArgs instead, and drop statement-adjacent comments to match the package's header-only comment convention.	2026-07-30 01:26:56 +08:00
7Sageer	fa2c5ce18b	feat: support plugin-contributed custom agents (#2365) ... * feat: support plugin-contributed custom agents * fix: await plugin loading before agent catalog * fix: refresh plugin agents on v1 reload * test(agent-core-v2): add enabledSystemPrompts to the plugin service stub	2026-07-29 21:59:48 +08:00
7Sageer	02d77b20d9	feat(agent-core-v2): let plugins contribute system prompt instructions via the manifest systemPrompt field (#2314) ... * feat(agent-core-v2): let plugins contribute system prompt instructions via the manifest systemPrompt field * feat(agent-core-v2): add systemPromptPath to load plugin system prompt from a file * docs: explain plugin system prompt templates * fix(agent-core-v2): refresh plugin system prompts after changes * fix(agent-core-v2): freeze restored profile bindings and converge plugin contributions at session scope - restore no longer re-renders or re-persists prompts: a resumed agent keeps its replayed profile binding (prompt and tool set) as persisted - a new Session-level convergence point reloads plugin skills into the session skill catalog before fanning out to every live agent prompt, and every catalog-kind plugin mutation awaits the whole pipeline; MCP-only toggles carry a distinct change kind and skip it - live refreshes after a restart re-resolve the bound profile by name and rebind the full slice (prompt, disallowed tools, active tools) atomically, warning and keeping the persisted state when the profile is gone; renders reuse the first-render timestamp and unchanged prompts are not re-persisted, so convergence never churns the wire - cap plugin system-prompt contributions (32 KB per field/file, 64 KB aggregate per prompt build) with manifest diagnostics and warnings - bump the changeset to minor: this is a new user-facing capability * fix(agent-core-v2): register the new session domain and dedupe the missing-profile warning - add sessionPluginContribution to the domain-layer registry so lint:domain stays green - emit system-prompt-refresh-profile-missing once per profile name, matching the service's other deduped warnings - document the convergence timeout escape hatch and the klient exclusion of enabledSystemPrompts * fix(agent-core-v2): dedupe the plugin budget warning and surface section read failures - emit plugin-sections-oversized once per skipped-plugin signature - let enabledSystemPrompts failures propagate to the refresh catch (keeps the current prompt and warns) instead of silently rendering and persisting a prompt without plugin instructions - cover the convergence timeout cut-off with a fake-timers test - clarify that the first-render timestamp anchors per process * fix(agent-core-v2): serialize session convergence and restore onDidReload timing - run at most one convergence per session and bound each change's wait by the timeout, so a fan-out emitter never interleaves deliveries after a timed-out convergence - fire onDidReload as soon as the reload commits again, keeping hook reloads independent of prompt convergence - sign the plugin budget warning with an unambiguous key * docs(agent-core-v2): align convergence wording with the serialized semantics - the timeout retry promise only holds once stalled work clears - note the per-session serial delivery cost model on the plugin change contract and the dual-queue invariant on the service * fix(agent-core-v2): keep empty plugin sections byte-neutral in the prompt template - place ${plugin_sections} on the same template line as ${skills_section} so prompts without either block render exactly as before this feature - note on the change contract that waitUntil work must not call back into plugin mutations, and spell out the per-session convergence order in the user docs * fix(agent-core-v2): pin a fork's profile so refresh triggers never rebind it - applyBindingSnapshot left the fork with no pinned profile, which routed in-process forks into the post-restart catalog rebind and could reset an inherited tool set; forks now inherit the source agent's pinned profile object - pin the first-render timestamp reuse with a ${now}-embedding test and document the anchored ${now} semantics - tighten the plugin docs budget and resume-refresh wording * fix(agent-core-v2): join in-flight convergence during agent bootstrap - an agent created while a plugin convergence is in flight now waits for it, and a restored agent refreshes once after it, so a plugin mutation never straddles an agent's bootstrap - warn on a non-string systemPrompt field and strip a UTF-8 BOM from systemPromptPath files before trimming - correct the consumption-surface wording (every CLI surface on the experimental flag, not just kimi -p), the per-session queueing note, and the single-plugin combined budget clause * fix(agent-core-v2): bound the bootstrap convergence join by the timeout A permanently wedged convergence kept convergeTail pending forever, and the unconditional settled() wait in bindBootstrap would have blocked every later agent creation in that session; the join now races the shared convergence timeout and continues (a restored agent still refreshes once, which never touches the tail), and the timeout constant moves to the contract for reuse * fix(agent-core-v2): close the convergence race against in-progress restores - a convergence fan-out could land while an agent's wire log is still replaying, dispatching a replay-visible config record whose effect the rest of the replay then overwrites; refreshSystemPrompt now skips while the wire restore is in progress - convergence completion is tracked by a generation counter; bootstrap compares it (after a bounded join) and refreshes a restored agent exactly once when a round completed after its creation began, replacing the wasConverging flag that could miss both windows * fix(agent-core-v2): bound each convergence so a wedged participant cannot stop the pipeline - the fan-out now races the convergence timeout, so convergeTail always settles: a permanently hung refresh delays its round (blocked entries drain oldest-first on later changes) instead of killing the session's convergence for good - warn when agent bootstrap stops waiting on a stalled convergence - diagnose a blank systemPromptPath and pin the plugin-root escape guard with traversal, absolute-path, and symlink tests * fix(agent-core-v2): bound the skill reload, preserve user-tool overlays, roll the prompt clock daily - the convergence's skill-reload segment now races the same timeout as the fan-out, so no segment of the pipeline can wedge a session for good; it continues with the previous catalog and retries next change - a cold rebind that resets the tool set replays session-added user tools onto the new base instead of dropping them for the rest of the process - the rendered timestamp re-anchors when the UTC date rolls over, so long-lived processes keep a fresh clock while steady-state renders stay byte-stable within a day - the plugin budget warning dedupes per plugin id, and the docs note that systemPromptPath content is frozen until the next reload * feat(agent-core-v2): converge cold plugin changes on resume through a drift-free gate - restore replays the persisted binding untouched, then bootstrap refreshes only when drift-free inputs changed while the session was cold: the catalog profile's tool set/denylist, or the plugin-sections baseline persisted alongside the prompt on the existing bind/update payloads; directory-listing and date drift wait for live triggers, so quiet resumes append no replay-visible records - the rendered timestamp is day-precision (UTC date at 00:00, re-anchored on rollover), keeping steady-state renders byte-stable across resumes and sessions on the same day - consolidate both timeout helpers onto a shared raceOutcome, and drop the generation counter the gate supersedes - align the plugin-sections precedence prose with the AGENTS.md disclaimer (no self-granted authority, system instructions win on conflict) * fix(agent-core-v2): bound the restored-prompt gate and land the sections baseline - the gate's plugin-sections read now races the convergence timeout, so agent creation never blocks behind an unrelated plugin mutation - refreshes serialize per agent through a tail, so overlapping triggers cannot write prompts out of order - when plugin sections change but a plugin-free custom prompt does not, the new baseline lands as a sections-only update instead of making every later resume re-render in vain - align the system prompt's Date and Time paragraph with the day-precision anchored timestamp * Update plugin system-prompt instructions in changeset Live sessions pick up plugin changes, while the default TUI and `kimi -p` paths ignore these fields. Signed-off-by: 7Sageer <sag77r@hotmail.com> * refactor(agent-core-v2): keep plugin skill reload user-driven Plugin mutations still converge live agent prompts, but the session skill catalog goes back to refreshing only on explicit plugin reload, as before: the prompt feature does not need skill convergence, and the pre-existing manual-reload semantics stay uniform across all plugin contributions. Removes the convergence-driven skill reload, the reloadSource de-privatization, and their tests; restores the PluginSkillSource onDidReload forwarding and its catalog tests. * refactor(agent-core-v2): apply plugin system-prompt changes only on explicit reload Drop the live convergence machinery (the plugin onDidChange barrier, the sessionPluginContribution fan-out, the restored-prompt drift gate, and the day-precision render clock) so plugin system-prompt sections take effect at the same point as every other plugin contribution: /plugins reload or a new session. The profile now refreshes when the session skill catalog re-pulls its plugin source on reload, reading both the skill list and the prompt sections fresh. * feat(agent-core): let plugins contribute system prompt instructions via the manifest systemPrompt field * chore(agent-core-v2): remove inline implementation comment * docs: clarify plugin prompt refresh semantics --------- Signed-off-by: 7Sageer <sag77r@hotmail.com>	2026-07-29 20:30:07 +08:00
wenhua020201-arch	f8ec3d1656	docs: fix dead anchor links in en/zh docs (#2348) ... * docs: fix dead anchor links in en/zh docs - #loop_control -> #loop-control (heading slug uses hyphens) - #secondary_model -> #secondary-model - env-vars model section anchors: kimi_model -> kimi-model - provider credential section anchors: configtoml -> config-toml - /provider management anchors: point at the renamed heading in each locale - hooks: point the stale config-files#hooks reference at the local Configuration section - en files: replace two leftover Chinese anchors with their English targets * docs: add missing .md extension to themes page links --------- Co-authored-by: qer <wbxl2000@outlook.com>	2026-07-29 15:57:48 +08:00
liruifengv	37d9bdc585	docs(changelog): sync 0.30.0 from apps/kimi-code/CHANGELOG.md (#2343)	2026-07-29 12:13:20 +08:00
7Sageer	efac96c8a9	feat(agent-core): custom agent files and secondary model on the v1 engine (#2232) ... * feat(agent-core): custom agent files and secondary model on the v1 engine Migrate the custom agentfile and secondary-model capabilities from agent-core-v2 to the v1 engine so they work in the TUI and plain kimi -p sessions: - discover Markdown agent files from user/project/extra/explicit directories with the v2 precedence rules, a merged session profile catalog replacing the hardcoded builtin profile lookups, SYSTEM.md main prompt override, and ${base_prompt} backed by the effective default - --agent/--agent-file now work in print mode on the default engine; CreateSessionOptions gains agentProfile/agentFiles - [secondary_model] config + KIMI_SECONDARY_MODEL/EFFORT bind newly spawned subagents to a cheaper model behind the secondary-model experiment flag, with primary/secondary model params on Agent and AgentSwarm and upfront session warnings - full disallowedTools deny semantics (exact names + mcp__ globs) evaluated by the tool manager and persisted in the agent wire * fix(cli): guard optional agentFiles in the prompt runner runPrompt is also driven programmatically (headless goal flow) with options that never pass through the CLI parser defaults, so agentFiles can be undefined; mirror the addDirs optional-chaining pattern. Also extend the SDK experimental-feature assertion with the secondary-model flag. * fix(agent-core): preserve custom agent bindings on v1 * fix(agent-core): narrow secondary model error hints * fix(agent-core): persist custom agent profile bindings * Delete .changeset/sdk-agent-profile-options.md Signed-off-by: 7Sageer <sag77r@hotmail.com> * Update v1-custom-agent-files.md Signed-off-by: 7Sageer <sag77r@hotmail.com> * Update v1-secondary-model.md Signed-off-by: 7Sageer <sag77r@hotmail.com> * Update v1-custom-agent-files.md Signed-off-by: 7Sageer <sag77r@hotmail.com> * fix(agent-core): keep SYSTEM.md a prompt-only overlay for delegation * docs: update agent file and secondary model availability wording * fix(cli): reject --agent-file combined with session resume The resume path only forwards the agent file's name for the bound-profile assertion; the file's content is never re-applied (the session keeps its creation-time catalog snapshot). Previously the combination was silently accepted, so an edited file (or a same-named one) appeared to apply but did not. Reject it at option validation and document the constraint. * refactor(agent-core): share prompt-section prose and note v2 twins in agentfile headers The Windows notes, additional-dirs and skills prose blocks existed twice: inline in the builtin default template (system.md) and as constants in the agent-file renderer (from-file.ts). Extract them to profile/prompt-sections.ts as the single source: system.md renders them through injected KIMI_* template variables and from-file.ts imports the same constants. Rendered prompts are byte-identical for all four builtin profiles across macOS/Windows and skills/dirs on/off; a new test pins system.md to the shared constants. Also mark each profile/agentfile file with the path of its agent-core-v2 counterpart so format/semantics changes land in both engines. * feat(cli): add /secondary_model command for the subagent model Mirror /model: a picker with a thinking-effort step that persists [secondary_model] and live-applies to the current session via a new Session.setSecondaryModel RPC (node-sdk wrapper included), so newly spawned subagents bind the new model right away. The /model picker now hides the synthesized __secondary__ derived entry; docs and the update-config builtin skill mention the section. * feat(tui): show the bound model in subagent run stats Subagents report their model alias via agent.status.updated after spawn; resolve it to a display name and surface it in tool-call subagent stats and agent-group rows. * fix(agent-core): validate agent profile before session persistence * fix(agent-core): refresh subagent tools after model switch * fix(agent-core): show subagent model preferences * fix(agent-core): preserve secondary model recipe on live apply * fix(agent-core): make secondary model apply explicit * fix(tui): refresh secondary model display state * chore: merge secondary model changesets into one * Add /secondary_model command for subagent configuration Show each subagent's model in the subagent card header and agent-group rows. Requires the secondary-model experiment (KIMI_CODE_EXPERIMENTAL_SECONDARY_MODEL=1); run /secondary_model to pick a model and thinking effort, applied to the current session immediately. Signed-off-by: 7Sageer <sag77r@hotmail.com> * fix(agent-core): align explicit agent file precedence * fix(agent-core): let disallowedTools deny select_tools * chore(cli): drop engine mention from --agent/--agent-file help text * feat(cli): support --agent/--agent-file in the interactive TUI Bind the selected agent profile to the startup session when launching the TUI with --agent/--agent-file, including the session created after an OAuth login at startup. Sessions created later in the process (/new) keep the default profile. Make both flags creation-only in every mode: combining them with --session/--continue is now rejected in print mode too, since resume restores the bound agent from the session automatically. * fix(agent-core): persist new secondary-model selections under env overrides stripSecondaryModelConfig restored secondary_model.model/default_effort from raw whenever KIMI_SECONDARY_MODEL/KIMI_SECONDARY_EFFORT was set, so a /secondary_model pick made under the env vars was silently discarded on write. Restore from raw only when the value being written still equals the env value (an overlay round-trip), mirroring the pointer check in stripEnvModelConfig; a genuinely different selection now reaches config.toml. * fix(cli): report the effective secondary model when env overrides the pick /secondary_model toasted the picked alias even when KIMI_SECONDARY_MODEL/KIMI_SECONDARY_EFFORT made the session bind a different model. Read the effective binding back from the reloaded config (as /model does from session status) and warn with the env-overridden values instead. * feat(tui): show the bound model name in the AgentSwarm panel header --------- Signed-off-by: 7Sageer <sag77r@hotmail.com>	2026-07-29 12:06:26 +08:00
Yufeng He	67dd03149f	feat(tui): customizable footer status line via status_line config (#2255) ... * feat(tui): customizable footer status line via status_line config The bottom status bar was a fixed layout. Add a [status_line] section to tui.toml covering the two established models: - items: codex-style composition. Pick and order the built-in slots (mode, goal, model, tasks, cwd, git, tips); unset keeps today's layout, unknown ids are skipped with a warning, and an empty list blanks line 1. - command: claude-code-style custom line. The footer runs the command with a JSON snapshot on stdin (model, cwd, git branch, permission and plan mode, context usage, session id, version) and renders the first stdout line. Runs are throttled to one per second and capped at 300ms; nonzero exit, empty output, or a timeout falls back to the built-in layout. Line 2 (context readout) stays built-in in every mode. Resolve #2116. * feat(tui): apply status_line on /reload-tui and document it The reload command pushes reloaded tui.toml fields into AppState; the new statusLine field joins that list so edits go live without a restart. The config files reference (EN/ZH) documents the new section. * fix(tui): round-trip active status_line on save and harden the runner Codex review on #2255 caught a real one: saveTuiConfig rewrites the whole tui.toml, so changing any other preference dropped an active [status_line] section. Render it live when set (items and command), commented-out guide when unset. Also: spawn the command through ComSpec/cmd.exe on Windows instead of assuming sh.exe, and take the whole process tree down on timeout (process-group kill on POSIX, taskkill /T on Windows) so a script that spawned children cannot leak them. * fix(tui): address status_line review: runner lifecycle, capture cap, tips slot - recreate the command runner when a reload swaps status_line.command; the old runner kept executing the previous script until restart - schedule a trailing refresh instead of dropping updates that arrive inside the throttle window, so the last state change always lands - stop accumulating stdout once the first line is complete (and cap a missing-newline stream at 64KB); only the first line is ever rendered - honor the configured position of the tips slot in items instead of always pinning tips to the far right - route unknown status_line.items warnings through the TUI status area on reload instead of raw stderr, which could corrupt the display Changeset text tightened per maintainer note. --------- Co-authored-by: Kai <me@kaiyi.cool>	2026-07-28 22:37:52 +08:00
Petrichor	cdbd33c13c	fix(kosong): fail fast on quota-exhausted 429 instead of retrying (#1857) ... * fix(kosong): fail fast on quota-exhausted 429 instead of retrying A 429 caused by an exhausted account quota or insufficient balance (Moonshot error.type "exceeded_current_quota_error", OpenAI "insufficient_quota") can never succeed on retry, yet it was classified as APIProviderRateLimitError and silently retried for the whole budget (10 attempts, ~3 minutes of backoff) with no UI feedback — the session appeared frozen on every request. Introduce APIProviderQuotaExhaustedError, minted in normalizeAPIStatusError from the structured body error.type/error.code forwarded by convertOpenAIError, with billing-anchored message patterns as a fallback for gateways that flatten the body to text. The new class is excluded from isRetryableGenerateError (fail fast, even when a retry-after header is present) and from isProviderRateLimitError (no swarm requeue/suspend). toKimiErrorPayload and translateProviderError map it to provider.api_error (retryable: false) instead of provider.rate_limit, and classifyApiError reports it as quota_exhausted in telemetry. agent-core-v2 mirrors the same fix. Transient rate-limit 429s keep the existing retry, backoff, and Retry-After behavior (verified end-to-end against a mock provider: quota body fails after attempt 1/10; rate-limit body still walks the full 10-attempt ladder). Behavior changes to note: quota-failed swarm subagents now fail instead of suspending indefinitely as "Rate limited...", and quota errors cross the wire as provider.api_error rather than provider.rate_limit. * fix(kosong): classify quota exhaustion in OpenAI Responses stream errors Responses response.failed / error SSE events carry no HTTP status and were minted by errorFromOpenAIResponsesEvent as either a rate-limit error (rate_limit_exceeded / embedded status_code=429) or a base ChatProviderError — and the base class falls into the retryable unclassified-failure fallback, so an insufficient_quota event still burned the whole retry budget on the openai_responses path. Route the event code and message through the same quota-exhausted check before the rate-limit branch, in kosong and the agent-core-v2 mirror. Covers all three entry paths (error events, response.failed, nested gateway frames) since they share the single converter. * style(agent-core-v2): drop inline comments per AGENTS.md header-only rule agent-core-v2 comments live solely in the top-of-file block, never beside functions or statements; the kosong twins keep the full rationale. * refactor(kosong,agent-core-v2): move quota-429 checks to vendor hook Per review on #1857: the knowledge of how a backend signals quota exhaustion is vendor-specific and must not run for every OpenAI-compatible provider from the shared conversion layer. - Add a convertError hook: ProtocolTrait.convertError in agent-core-v2 (single-value, last-declarer-wins, bound by composeOpenAIChatHooks / composeAnthropicHooks / traitConvertError) and an equivalent optional hook parameter on convertOpenAIError / convertAnthropicError. Bases consult it with the raw failure (SDK error on HTTP paths, raw event on the Responses in-stream path) after the abort guard, before their own rules. - Declare Moonshot's quota signals (exceeded_current_quota_error, billing wordings) on the Kimi side: kimiOpenAITrait and kimiAnthropicTrait in v2, the KimiChatProvider and KimiFiles catch sites in kosong, all through the new classifyKimiQuotaError. - Drop the options parameter from normalizeAPIStatusError and the shared quota code/pattern tables: the contract layer keeps only the vendor-neutral APIProviderQuotaExhaustedError type and its retry / rate-limit / wire-mapping semantics. - The OpenAI bases keep recognizing only OpenAI's own documented insufficient_quota code (HTTP and Responses stream events) as protocol knowledge of that wire. Behavior: kimi and openai provider types classify exactly as before; an unregistered vendor speaking Moonshot billing wordings through a plain openai transport now stays a retryable rate limit by design. * fix(kosong,agent-core,agent-core-v2): wire kimi quota hook fully Follow-up to the second review round on #1857, all four findings: - Kimi-over-Anthropic (legacy engine): AnthropicOptions gains the same optional convertError hook as the OpenAI bases, threaded through AnthropicStreamedMessage and every catch site, and the provider manager's anthropic route now passes classifyKimiQuotaError for provider type kimi — a quota-exhausted 429 over this transport previously still burned the retry budget. classifyKimiQuotaError now also walks error -> .error -> .error.error for the code/type, since the Anthropic SDK keeps the full body on .error instead of hoisting. - v2 telemetry: ApiErrorKind gains 'quota_exhausted' and classifyApiError checks APIProviderQuotaExhaustedError before the generic 429 branch, matching the legacy engine's reporting. - Hook contract: converted ChatProviderErrors now pass through before the vendor hook is consulted in convertOpenAIError / convertAnthropicError (both engines), so the hook sees each raw failure exactly once even when a stream-minted error crosses an outer catch; tests assert the single consult. - protocolTrait: the convertError member doc shrinks to the concise style and the consult contract moves into the file header's composition rules. * test(kosong,agent-core,agent-core-v2): lock quota hook assembly paths Third review round on #1857: - Fix the v2 anthropic base header and AnthropicHooks doc still claiming withThinking is the only hook. - Drop the two remaining non-header JSDoc blocks in protocolTrait.ts per the AGENTS.md header-only rule; the consult contract already lives in the file header. - Update the ProtocolTrait contract test to the seventeen-hook shape (convertError included) and cover the traitConvertError binding. - Add real-assembly regression probes: the v2 registry composes a (kimi, anthropic) provider whose mocked SDK client throws a Moonshot quota 429 and generate rejects with the non-retryable APIProviderQuotaExhaustedError (a plain anthropic composition keeps the same 429 retryable); the legacy ProviderManager routing test asserts convertError is classifyKimiQuotaError on the kimi-anthropic route and absent for plain anthropic; the legacy provider threads options.convertError to its generate catch. * test(kosong,agent-core-v2): cover KimiFiles quota 429 and drop stale docs Fourth review round on #1857: - Drop the AnthropicHooks member JSDoc (its content already lives in the anthropic.ts and anthropicHooks.ts file headers) and fix the anthropic contrib header still calling the hook set single-hook. - Add the missing KimiFiles regression in both engines: a mocked files client rejecting with a Moonshot quota 429 makes uploadVideo reject with the non-retryable APIProviderQuotaExhaustedError, locking the classifyKimiQuotaError argument at the upload catch sites.	2026-07-28 14:35:12 +08:00
qer	29783e471a	feat(cli): add plugin quota and update notices (#2147) ... * feat(cli): add plugin quota and update notices - Show "Note: This plugin consumes your quota." after installing quota-consuming official plugins (currently Kimi Datasource). - Show a one-time update notice after invoking an outdated plugin (a plugin MCP tool call or a /<plugin>:<command> turn); the last notified version is persisted so each new marketplace version reminds once. - Skip the third-party trust prompt for loopback sources that mirror the official plugin CDN path, so the dev plugin marketplace no longer prompts when installing official plugins. * feat(cli): report plugin update notices at turn end Buffer plugin MCP tool usage during the turn and report it together with plugin command usage when the turn's output has fully ended, instead of firing the check mid-turn at tool result time. Cancelled turns no longer trigger the notice. * fix(cli): refresh plugin MCP map on miss and serialize notice writes Address review findings on the plugin update notifier: - The memoized MCP server-to-plugin map is reused across /reload, /new, and session switches, so plugins installed or enabled later in the same app run never resolved. Refresh the map once on a lookup miss, and never pin an empty map when there is no session. - Concurrent notices (a turn that used two outdated plugins) raced on the read-modify-write cycle of the notice state file and could drop each other's entries. Serialize checks through a promise queue so each notified version is persisted exactly once. * fix(cli): gate plugin notices on official provenance and survive tool-name truncation Address review findings: - The quota note and the update notice keyed on the plugin id alone, so a local/GitHub fork reusing a billed plugin's manifest id was treated as the official build. Both now require official provenance (a zip install from the official CDN plugin path or its loopback dev mirror) via a shared isOfficialPluginInstall check. - Resolving plugin MCP tools by splitting on the '__' separator broke for qualified names core truncates to 64 chars, which can cut the separator. Match known server names by longest prefix with a name boundary instead, which survives truncation as long as the server part itself is intact. * revert(cli): drop the dev marketplace trust relaxation The loopback carve-out let any local service bypass the third-party trust prompt by serving a zip under the official path shape, which does not prove official provenance (review P1). Revert to the single rule — only https://code.kimi.com/kimi-code/plugins/official/* is a trusted official source — and restore the stock dev marketplace server. Installing official plugins from the dev marketplace shows the trust prompt again. * fix(cli): restrict update notices to the official catalog and settle tests - Skip the update check when the loaded marketplace is not the default official catalog, so a custom KIMI_CODE_PLUGIN_MARKETPLACE_URL can no longer produce a notice that claims to come from the Official Marketplace. - Return a never-rejecting promise from the notifier entry points so tests await the serialized queue directly instead of relying on zero-delay timers for ordering.	2026-07-27 17:00:42 +08:00
liruifengv	a9af42e698	docs(changelog): sync 0.29.2 from apps/kimi-code/CHANGELOG.md (#2236)	2026-07-27 15:04:24 +08:00
7Sageer	d40d0d305d	refactor(agent-core-v2): make undo domain-owned (#2055) ... * refactor(agent-core-v2): rebuild undo as wire-level journal rewind Replace the compensating context.undo op with a wire-layer rewind primitive: a log.cut control record with a persisted target, applied uniformly by the wire during fold. Turn boundaries become first-class (TurnIndexModel indexing turn.prompt record positions), models declare a temporal classification (rewindable), and a single IAgentRewindService owns the undo pipeline (quiesce -> precheck -> cut -> reconcile) with all entry points converged. - wire: log.cut record, rewindable model flag, re-fold rebuild; OpApplyContext.recordIndex for position-aware reducers - rewind service: aborts the active turn, cancels in-flight compaction, preserves the pending queue, rebases measured tokens, reconciles lastPrompt, tracks conversation_undo - todo list, plan mode, task-notification delivery and the turn index now rewind together with the undone turns - transcript reducer applies cut ranges so snapshot/messages surfaces stay consistent with the model context - REST/RPC/debug undo entry points converge on the rewind service; TUI parses the v2 undo-unavailable error shape - legacy context.undo records keep replaying for old journals * refactor(agent-core-v2): keep undo domain-owned * refactor: enhance /undo functionality for consistency and safety, including todo list rollback and improved event handling * chore: clean up undo changeset artifacts * refactor: rebuild rewind consistency * fix: make conversation undo durable and consistent * fix(agent-core-v2): stabilize undo restoration * fix: keep TUI undo on legacy error contract * refactor(agent-core-v2): drop unused full compaction cancel API Undo now rejects with session.busy while compaction runs instead of cancelling it, so the awaitable cancel() added for the earlier rewind semantics has no callers left. Remove it from the interface and implementation; the RPC cancel path keeps using the task abort controller directly. * fix(agent-core-v2): remove injected context on undo * chore(agent-core-v2): regenerate wire manifest * docs(agent-core-dev): rename rewind to undo in layer table * fix(agent-core-v2): undo prompt-owned image reminders * refactor: remove transcript undo reconciliation * fix(kap-server): map undo busy errors * refactor(agent-core-v2): rename undo participant registry and attribute checkpoint depth - Rename IAgentConversationUndoReconciliationRegistry to IAgentConversationUndoParticipantRegistry (conversationUndoParticipants). - Return the limiting model from checkpointDepth and include it in the SESSION_UNDO_UNAVAILABLE details; report checkpoint_lost instead of compaction_boundary when no compaction explains the missing depth. - Add a registry invariant test: every model reacting to context.* ops must be registered via defineCheckpointedModel or explicitly exempt. * Delete .changeset/fix-undo-injections.md Signed-off-by: 7Sageer <sag77r@hotmail.com> --------- Signed-off-by: 7Sageer <sag77r@hotmail.com>	2026-07-27 11:09:26 +08:00
liruifengv	c2b2c4eb49	docs(changelog): sync 0.29.1 from apps/kimi-code/CHANGELOG.md (#2136)	2026-07-24 13:56:33 +08:00
7Sageer	7b62ed5b2c	feat: support a configurable secondary model for subagents (#2064) ... * feat: support a configurable secondary model for subagents * refactor: move the subagent model config to a consumer-neutral [secondary_model] The secondary model becomes a model-domain concept next to default_model so future consumers beyond subagents can share it: [secondary_model] model / effort in config.toml, KIMI_SECONDARY_MODEL / KIMI_SECONDARY_EFFORT env overrides, and the Agent / AgentSwarm per-spawn choice renamed from "subagent" to "secondary". * docs: replace "v2 engine only" notes with the concrete effective surfaces State that [secondary_model], its env overrides, the Agent/AgentSwarm model parameter, and SYSTEM.md take effect only under kimi web and experimental kimi -p (the TUI ignores them), and that --agent / --agent-file are available only under experimental kimi -p. Also drop the SYSTEM.md claim of parity with --agent/--agent-file, which was inaccurate: SYSTEM.md is an agent-core-v2 app-domain feature and also applies under kimi web, while the flags are gated at the CLI. * fix: review follow-ups for the subagent secondary model - Drop the "cheaper" claim from the Agent/AgentSwarm model parameter descriptions and the advertised model list — the secondary model is not necessarily the cheaper one. - Downgrade the changeset to patch, note the kimi web / experimental kimi -p effective surface, and tighten the wording. - Remove the onWillRestore stub fields from two lifecycle stubs; they belong to upcoming lifecycle work, not to this change. * fix(agent-core-v2): prevent ghost agents from invalid model bindings * fix: narrow the secondary-model error hint to missing-alias failures The model catalog's not-configured throw now carries details.model, and wrapSubagentModelError only decorates errors whose details.model matches the bound model. Malformed [models.*] entries and unrelated config.invalid failures during agent creation pass through untouched instead of being misattributed to an invalid secondary-model alias. * fix: mark subagent resume semantics as breaking * chore(agent-core-v2): follow header-only comment convention * fix(agent-core-v2): await agent restore preparation * feat(agent-core-v2): support agent model preferences * Update subagent-secondary-model.md Signed-off-by: 7Sageer <12210216@mail.sustech.edu.cn> * fix: validate secondary models before agent creation * Delete .changeset/secondary-model-startup-warning.md Signed-off-by: 7Sageer <12210216@mail.sustech.edu.cn> * Add secondary_model config section for subagents Individual agents can override this via the new `model_preference` field in their agent file. Signed-off-by: 7Sageer <sag77r@hotmail.com> * feat(agent-core-v2): support override patches in [secondary_model] The recipe is now `model` plus the flattened ModelOverride field set. With any patch field set, a config overlay synthesizes a derived registry entry (base copy, patch merged into overrides, aliases dropped) so subagent spawning rides the standard effectiveModelConfig merge; with none, subagents bind the pointed entry directly. `default_effort` replaces `effort` (KIMI_SECONDARY_EFFORT rebinds) and doubles as the explicit subagent thinking; unset, thinking resolves naturally instead of inheriting the caller. The overlay strips the derived entry (and any defaultModel pointer to it) from writes, and the kap-server GET /models route hides it from pickers. * fix(agent-core-v2): fire section events for overlay-rewritten domains rebuildEffective only committed the caller-named domains, so a ConfigEffectiveOverlay or section env binding that rewrote a sibling domain (setting [secondary_model] synthesizes a derived models entry; removing the recipe retracts it) left consumers of the models section stale. Widen the commit candidates with every domain the recompute actually changed; commit() deepEqual-guards each candidate, so the widening costs nothing. * feat(agent-core-v2): gate secondary model behind experimental flag * Update subagent-secondary-model.md Signed-off-by: 7Sageer <sag77r@hotmail.com> --------- Signed-off-by: 7Sageer <12210216@mail.sustech.edu.cn> Signed-off-by: 7Sageer <sag77r@hotmail.com>	2026-07-24 12:16:53 +08:00
7Sageer	5fdbdb4a22	feat: configure web search/fetch services via KIMI_WEB_* env vars (#2096) ... * feat: configure web search/fetch services via KIMI_WEB_* env vars KIMI_WEB_SEARCH_BASE_URL / KIMI_WEB_SEARCH_API_KEY and KIMI_WEB_FETCH_BASE_URL / KIMI_WEB_FETCH_API_KEY overlay the [services] config section field by field in both engines (env wins over config.toml), so the WebSearch and FetchURL backends can be pointed at a Moonshot service without OAuth login. The v2 engine now also honors the explicit [services.moonshot_fetch] section (config > managed OAuth > local), which it previously parsed but never consumed. * fix(agent-core-v2): guard stripServicesEnv against clearing the services section config.replace(SERVICES_SECTION, undefined) — the logout deprovisioning path in authService — passes undefined straight into the section strip, and the composed stripServicesEnv dereferenced it (value[key]), throwing TypeError and aborting logout mid-cleanup. Add the same isPlainObject guard the other strip implementations (stripProvidersEnv, stripEnvBoundFields) already have, plus a regression test that also locks in the env overlay staying effective after the file value is cleared. * style(agent-core-v2): follow header-only comment convention * fix: isolate env web service credentials * Add env vars for web search and fetch services The new environment variables `KIMI_WEB_SEARCH_BASE_URL`, `KIMI_WEB_SEARCH_API_KEY`, `KIMI_WEB_FETCH_BASE_URL`, and `KIMI_WEB_FETCH_API_KEY` take priority over the corresponding fields in `config.toml`. The `kimi web` backend now honors the `[services.moonshot_fetch]` config section. Signed-off-by: 7Sageer <sag77r@hotmail.com> --------- Signed-off-by: 7Sageer <sag77r@hotmail.com>	2026-07-23 17:36:16 +08:00
7Sageer	527d485d92	feat: add global default MCP server timeout configs (#2065) ... * feat: add global default MCP server startup timeout config Add a `[mcp] startup_timeout_ms` config.toml section with a `KIMI_MCP_STARTUP_TIMEOUT_MS` env override as the global default MCP server connection (startup + tool discovery) timeout. Precedence: per-server `startupTimeoutMs` in mcp.json > env var > config.toml > built-in 30s default. * feat: add global default MCP tool call timeout config Extend the `[mcp]` section with `tool_timeout_ms` and the `KIMI_MCP_TOOL_TIMEOUT_MS` env override as the global default for single MCP tool calls, mirroring the startup timeout: a per-server `toolTimeoutMs` in mcp.json still wins, and unset entries fall back to the SDK built-in 60s default. * chore: shorten the mcp timeouts changeset * feat(agent-core): add global default MCP server timeout configs Port the `[mcp]` section (`startup_timeout_ms` / `tool_timeout_ms`) and the `KIMI_MCP_STARTUP_TIMEOUT_MS` / `KIMI_MCP_TOOL_TIMEOUT_MS` env overrides to agent-core (v1), mirroring the v2 semantics: per-server fields in mcp.json > env vars > config.toml > built-in defaults. The v1 TOML loader gains explicit `mcp` read/write mappings, and both connection-manager construction sites (Session, testGlobalMcpServer RPC) pass the resolved defaults through. * fix(agent-core): validate and apply MCP timeout defaults * fix: propagate MCP startup timeout to SDK requests * refactor(agent-core-v2): resolve MCP default timeouts at connect time Keep the session connection manager synchronously lazy instead of gating its existence on config readiness: resolveDefaultTimeouts is read from the mcp config section at each (re)connect, so AgentMcpService's eager construction stays unconditionally safe and reconnects pick up changed preferences. The initial connect still awaits config.ready for a deterministic snapshot. Also restore the ISessionMcpService method docs, bump the changeset to minor, and fix the v1 env-parse comment. * chore(agent-core-v2): regenerate config manifest for the mcp section * Add global default MCP server timeouts configuration Specify the new global default MCP server timeouts in both the config file and environment variables. Signed-off-by: 7Sageer <sag77r@hotmail.com> --------- Signed-off-by: 7Sageer <sag77r@hotmail.com>	2026-07-23 12:41:08 +08:00
qer	e0f2a41769	feat(datasource): add wind, imf, gildata, sec_edgar, and sp_data sources (#2029) ... * feat(datasource): add wind, imf, gildata, sec_edgar, and sp_data sources * feat(datasource): strengthen source routing in skill and tool schema * feat(datasource): retry on credential rotation and enforce single-source routing contract * feat(datasource): neutral source selection with objective capability boundaries * feat(datasource): note wind_search_fields field-name mapping in skill and schema	2026-07-22 22:45:55 +08:00
liruifengv	b32170b018	docs(changelog): sync 0.29.0 from apps/kimi-code/CHANGELOG.md (#2054)	2026-07-22 18:23:48 +08:00
Haozhe	8250e590f3	docs(cron): drop references to the non-existent kimi resume command (#2050) ... * docs(cron): drop references to the non-existent `kimi resume` command - point user docs at the real resume command `kimi --session` - reword cron tool descriptions and code comments in agent-core and agent-core-v2 to describe session resume without naming a subcommand * chore: add changeset for cron docs wording fix	2026-07-22 16:59:08 +08:00
Kai	ba921ca531	fix: gate always-thinking inference to OpenAI wires, plus catalog review follow-ups (#2036) ... * fix: gate always-thinking inference to OpenAI wires, plus review follow-ups - catalog: strip the inferred alwaysThinking marker on non-OpenAI wires so Claude/Gemini keep their native off; verified against live models.dev - v1 provider-manager: honor per-alias baseUrl on kimi/google-genai/vertexai - thinking: rewrite the PHASE-6 contract comment, drop three dead cannot-disable warning branches, normalize requested effort in v1 to match v2 - tests: input-cap compaction preference in both engines, kap-server WS status cap, v2 legacy status input cap - docs + changeset: new model fields, catalog-refresh behavior, kap-server * fix: strip always-thinking only where the wire encodes a true off The previous gate kept the marker only on the OpenAI wires, which wrongly stripped it from Gemini 3 on the Google wires: its floor is thinkingLevel MINIMAL with suppressed thoughts — still reasoning — so an Off option there would be a lie. The criterion is now the wire's encoding, not its family: strip only on anthropic and kimi, the two wires with a protocol-level `thinking: {type: 'disabled'}` that the catalog's effort list can never show. Verified against live models.dev data: google now marks exactly the gemini-3 family (10), anthropic and moonshotai stay 0. * docs(agent-core-v2): move the strict-validation contract into the thinking.ts file header The scoped guide keeps comments in the top-of-file block only; the function JSDoc shrinks to a short what-it-answers note matching its neighbors. No behavior change.	2026-07-22 13:43:10 +08:00
Kai	b5efba7abc	fix: consume the model metadata declared by the models.dev catalog (#2015) ... * fix: stop advertising Claude thinking efforts for non-Claude models Models served over the Anthropic protocol whose names carry no Claude marker (e.g. a catalog-imported Kimi K3) no longer inherit the latest Opus effort list, so the model selector stops offering levels the model does not accept. The models.dev catalog import now also parses reasoning_options and records the declared effort levels on the model alias, so K3 offers its real levels (low / high / max). * fix: consume deprecated, override, and input-limit metadata from the models.dev catalog - Models declared status=deprecated in the catalog are no longer offered for import. - Per-model provider overrides on gateway providers (an npm package targeting an Anthropic SDK plus a usable endpoint) now land as alias protocol and base_url, so those models are served over the right protocol and endpoint; overrides without a usable URL are skipped. - A declared limit.input now sizes the context budget instead of the larger total context window (e.g. gpt-5: 272k instead of 400k). The model alias schema gains an optional base_url field (not accepted in overrides) that Anthropic wire resolution prefers over the provider-level base URL. * fix: honor thinking-disable semantics and the OpenAI-compatible fallback in catalog imports - reasoning_options 'none' is the model's off encoding: off_effort flows from the catalog through the model alias to the OpenAI wire providers, so turning thinking off sends 'none' instead of omitting the effort field; models with effort levels but no way to disable thinking are imported as always_thinking and no longer offer an Off option. - Bare Claude family aliases (e.g. sonnet-latest) recover the inferred Anthropic effort profile; v2 comment conventions restored. - Providers whose SDK the catalog does not type now fall back to the OpenAI-compatible wire (with a visible "guessed" note) instead of being refused; imports lacking a usable endpoint ask for one (--base-url on the CLI, a prompt in the TUI). Proprietary SDKs (Amazon Bedrock), unrecognized explicit types, and env-placeholder URLs are refused with a clear reason. * fix: align catalog imports with the reference models.dev consumer - A JSON null tier in declared effort values is now read as the 'none' off-encoding (previously such models were wrongly imported as always-thinking with no way to turn reasoning off). - Alpha-status models are filtered out alongside deprecated ones. - Models whose per-model provider override targets a wire that cannot be expressed per-model (e.g. Claude on google-vertex, whose wire here is Gemini-mode Vertex, or gpt entries on an Anthropic provider) are skipped instead of being imported under the silently wrong protocol. - interleaved: true no longer pins reasoning_content: the provider's default three-field scan is wider and the pinned key only narrowed reasoning parsing for gateways answering with another field name. * fix: require endpoints for Anthropic-compatible catalog imports and honor --base-url - catalogProviderNeedsBaseUrl now covers the Anthropic wire: a non-official Anthropic-compatible vendor without a concrete catalog endpoint (e.g. google-vertex-anthropic) must supply --base-url / the TUI prompt instead of silently falling back to the default Anthropic endpoint. - --base-url now takes precedence over the catalog-declared endpoint, and an empty --base-url is rejected instead of persisting a blank endpoint. * fix: enforce always-on thinking on every wire and refuse Cohere at import A model that declares always_thinking (e.g. a catalog-imported gpt-5) no longer resolves to a dishonest off state via thinking.enabled=false or an SDK/ACP off request: resolution clamps to the model's default effort on every wire instead of letting upstream keep reasoning while the UI reports Off. The Anthropic warn-and-send path for unlisted effort levels is unchanged. Cohere's proprietary SDK joins Amazon Bedrock on the import-refusal list instead of being guessed as OpenAI-compatible. * fix: harden catalog import edge cases - An explicit but unrecognized catalog type is now refused before npm/id inference, so a future catalog protocol is never silently miswired through the OpenAI fallback. - User-supplied --base-url values for Anthropic-wire providers get the same trailing-/v1 normalization as catalog endpoints, avoiding /v1/v1/messages requests. - The TUI import prompt rejects env-placeholder base URLs like the CLI does. * fix: await the floating assertion promise in the catalog add CLI test * refactor: unify catalog import resolution into a single decision function Wire-type inference, the OpenAI-compatible fallback, proprietary-SDK refusal, endpoint adaptation, and the base-URL requirement are now produced together by resolveCatalogImport, one pure resolver consumed by both the CLI and the TUI — replacing the cooperating predicates (inferWireType, isGuessedWireType, catalogProviderNeedsBaseUrl) whose permutations kept producing edge cases. No behavior change. * fix: close configured-off clamp hole, keep inferWireType compat, carry same-wire override endpoints - A configured thinking.effort = "off" no longer bypasses the always-on clamp: it is treated as absent and the model default applies, mirrored on both engines. - The previously public inferWireType stays as a deprecated compatibility wrapper over resolveCatalogImport so existing SDK consumers do not break on a patch release. - Catalog model overrides that stay on the provider's wire but declare their own endpoint now persist it on the alias (and the v1 OpenAI wire branches honor alias-level base URLs like the Anthropic branch). * fix: split total window from input cap and close override/endpoint gaps - max_context_tokens once again means the total context window (used by completion budgeting); a model's declared input limit is tracked as max_input_tokens, which compaction, context-splice and usage-ratio checks prefer — fixing the over-clamping introduced when the input cap was stored as the context budget. - A catalog endpoint declared only as an env placeholder now always produces needs-base-url (official SDK included), so credentials are never sent to the public vendor host by default. - api-only per-model overrides are honored as same-wire endpoint changes; overrides targeting another known but inexpressible wire (e.g. google-genai on an OpenAI gateway) are skipped; same-wire models whose declared endpoint is an unusable placeholder are skipped instead of silently rerouted. * style: drop a function-level comment from the v2 thinking resolver * chore: consolidate the PR's changesets into two user-facing entries	2026-07-22 01:23:31 +08:00
Kai	37eda4e59a	feat(config): add env overrides for loop control and background task limits (#1993) ... * feat(config): add env overrides for loop control and background task limits Add three operational environment overrides, resolved as env > config.toml > default in both engines (agent-core and agent-core-v2), matching the existing KIMI_IMAGE_MAX_EDGE_PX / KIMI_SUBAGENT_TIMEOUT_MS pattern: - KIMI_LOOP_MAX_STEPS_PER_TURN overrides loop_control.max_steps_per_turn - KIMI_LOOP_MAX_RETRIES_PER_STEP overrides loop_control.max_retries_per_step - KIMI_CODE_BACKGROUND_MAX_RUNNING_TASKS overrides background.max_running_tasks Invalid values are ignored and fall back to the config value. The v2 engine resolves them through config section env bindings (effective-only, never persisted); the v1 engine resolves them at the consumption point. * fix(config): strip env-bound fields before persisting config writes Environment overrides resolved into the effective config could be echoed back through IConfigService.set/replace (e.g. GET then POST /api/v1/config) and persisted into config.toml, outliving the env var. This affected the pre-existing image / subagent / keep-alive bindings as well as the new loop control and max-running-tasks bindings. Extend ConfigStripEnv with a getEnv parameter and add a shared stripEnvBoundFields helper: while a field's env var is set, writes restore the field's raw on-disk value (or drop it) instead of persisting an echoed env value; when unset, normal writes persist. Register it for the loopControl, task/background, image, and subagent sections. Also fix ConfigService.stripEnv looking up rawSnake by the camelCase domain key; on-disk sections are keyed snake_case. * fix(config): honor binding parsers when stripping env fields on persist An invalid env value (e.g. KIMI_LOOP_MAX_STEPS_PER_TURN=abc) is ignored on the read path but still marked the field env-owned on the write path, so a config write for that field was silently dropped. stripEnvBoundFields now derives the guard from the section's envBindings and skips fields whose env value fails the binding's parse, so invalid env values are ignored on both paths — and the duplicated field/env descriptor list is gone. Also drop function-level comments added beside helpers; agent-core-v2 keeps comments solely in the top-of-file block, so the strip semantics now live in the config.ts / configService.ts headers. * fix(config): re-apply env overlays from the env-free base on every read Two follow-ups from review: - ConfigService.get()/getAll() re-applied section env bindings on the already-overlaid effective cache (and get() mutated it in place), so a valid override degraded to invalid or unset kept serving the stale value until the next reload — and an echoed stale value could then be persisted by a config write. Reads now recompute from a cached env-free validated base, so degraded or removed env values fall back to the file immediately. - stripEnvBoundFields restored env-owned fields from the raw snake sub-object, missing values persisted under legacy keys (e.g. max_steps_per_run). Section stripEnv now receives the env-free, fromToml-normalized raw base, so legacy aliases are honored. * test(kap-server): retry temp-home cleanup in auth tests auth.test.ts removed its temp home with a plain recursive rm, which races late async writers in the server shutdown path and flakes with ENOTEMPTY (seen on main CI and locally on main). Harden the cleanup with the same maxRetries/retryDelay options sessions.test.ts already uses. * chore(changeset): consolidate the env-override changesets into two entries One feature entry (loop/background env overrides, both engines plus the CLI) and one fix entry (env values persisting on writes and sticking after degrade/unset, agent-core-v2 plus the CLI). * fix(config): clear fully-stripped sections and refresh overlay domains on get() Two follow-ups from review: - stripEnvBoundFields returned an empty object when every written field was env-owned, so a section with a non-empty default (e.g. subagent) stored raw = {} and the default stopped applying until the next reload. A fully stripped result now clears the raw section instead. - get(domain) only recomputed env overlays for sections with env bindings, so domains written solely by a ConfigEffectiveOverlay (models / defaultModel from KIMI_MODEL_NAME) kept serving stale cached values after the env changed. get() now derives every non-memory domain from the fresh env-free base, matching getAll(). * test(config): drive the get() overlay freshness test with an inline overlay The previous version imported the model env overlay to activate it, which the CI runners failed to resolve from this test file (both tsgo and vitest, while the same specifier resolves elsewhere — not reproducible locally). An inline ConfigEffectiveOverlay double exercises the same ConfigService contract with a tighter seam and no module dependency. * fix(config): preserve unknown fields on full strip and clone nested env targets Two follow-ups from review: - stripEnvBoundFields cleared the raw section whenever the stripped result was empty, so an env echo write could drop unknown forward-compatible fields from the TOML table. An emptied section now keeps its raw table while the env-free base still holds other fields, and is cleared only when nothing remains (defaults keep applying). - applyEnvBindings reused nested child objects in place, so a nested env binding on a persistable key would mutate the env-free validated base and serve stale values after the env var is removed. Children are now cloned before descending. * fix(config): keep the env-free base when a strip leaves nothing to persist Returning {} for a fully stripped write stored the empty object into the raw layer while the TOML table survived via rawSnake, so the bases diverged; a second echo write then saw an empty base, cleared the section, and deleted the table — dropping unknown forward-compatible fields. When nothing persistable remains, the write is now a no-op for the section (the env-free base is kept as-is), and the section is cleared only when the base is empty. * fix(config): revalidate stripped results so restored raw values never persist A strip may restore on-disk values from the unvalidated raw base (e.g. an env-masked invalid field), smuggling them past the merge-time validation into the stored config: the section would then fail the next buildValidated pass, dropping accompanying valid edits from the runtime while the invalid value stayed persisted. set() now revalidates the stripped result — discarding the parse output so unknown fields survive — and rejects the write instead, matching replace().	2026-07-21 19:49:00 +08:00