* feat(kap-server): accept bundled skill activations on the prompt submission route The bundled-submission capability was only reachable through the in-process klient transports; the App talks to kap-server over /api/v1. The submit-prompt route now accepts an optional non-empty skills field and delegates to IAgentSkillService.promptWithSkills — same validation, events, and single bundled user message as the TUI path — skipping its own prompt-metadata update (the engine owns it there) and mapping skill.not_found / skill.type_unsupported onto the skills route's codes. To return the submission's queue identity, the engine's promptWithSkills now resolves with prompt_id / user_message_id / created_at / state (plus turn_id once launched), mirrored through the klient contract. * refactor(agent-core-v2): slim the promptWithSkills result contract Drop the user_message_id field (it is always the same identity as prompt_id — the route duplicates it) and narrow state to the running/queued/blocked vocabulary, mapped at the engine edge instead of exposing the internal seven-state PromptState on the wire. * fix(kap-server): harden bundled skill submissions against review findings - Validate bundled skill names and types before any media materialization or control override, so a rejected bundle leaves session state untouched (the engine still re-validates authoritatively). - Declare the 40415/40912 outcomes on the submit route so the generated API documentation includes them. - The klient output schema no longer tolerates a missing promptWithSkills result (a transport-level absence now raises instead of resolving undefined), and a failed launch surfaces as an error rather than a successful running result. - Add the changeset for the new public API field. * fix(kap-server): preflight bundled skills before agent materialization and stabilize listed content - Skill preflight now runs on the session's catalog before the main agent is resolved, so a rejected bundle cannot mutate session metadata by registering main (regression test on a cold session without an agent). - The prompts list projection strips the stored skill blocks from a bundled prompt, so GET /prompts returns the same caller-only content as the submit response. * fix(kap-server): reject bundled prompt_id combos at preflight and clean queued staging - The skills + prompt_id incompatibility rejection now runs at the initial bundled preflight, before the main agent is materialized or any override binds (previously a yolo override could bind before the 40001). - Queued bundles no longer skip staging cleanup forever: the discard is deferred to the bundle's prompt.completed / prompt.aborted lifecycle event, mirroring the plain path's launch-raced cleanup. * fix(kap-server): clean queued bundle staging on the steer path too A queued bundle steered into the active turn is consumed at steer time, but the engine publishes prompt.completed/aborted only for the parent — the deferred cleanup never fired and its subscription leaked. The prompt.steered event (matching promptIds) now counts as the child's intake-completion signal. * fix(agent-core-v2): materialize daemon-ref media on the steer and inject paths startNext materializes daemon file references into the session media store before a prompt's turn, but steer() and inject() enqueued the same references without that intake, leaving the staging upload as the only copy — any staging cleanup at steer time would delete the media the turn is about to consume. Both paths now run the same intake before the SteerStepRequest is created, so prompt.steered is a truthful intake-complete signal. * fix(kap-server): defer staging cleanup to turn settlement, never to steer time Prompt-intake materialization is best-effort: when it degrades, the daemon upload is the request-time resolver's fallback source. Discarding staging at prompt.steered could therefore delete the only readable copy before the parent's request ran. Cleanup is now uniformly event-driven — the bundle's own prompt.completed/aborted, or the steer parent's — so the upload always outlives the request it feeds. * fix(kap-server): install settlement tracking before bundled enqueue A hook-blocked bundle completes synchronously inside the submission call, and an exceptionally fast launch can settle just as early — a post-call subscription misses the only settlement event and leaks both the staging blob and the listener. The tracker now subscribes before enqueueing, buffers lifecycle events, and settles against the returned prompt id (or its steer parent's). * fix(kap-server): scope settlement tracking to the owning agent and dispose on rejection - The tracker now subscribes through the agent-scoped IEventBus instead of the App-scoped IEventService: prompt lifecycle events from other sessions never reach it, so a colliding client-chosen prompt id cannot trigger a foreign settlement (and the steer re-target only follows this agent's parent). - A bundled submission that rejects after the tracker was installed now disposes it on the error path instead of leaking a permanent listener. * fix(agent-core-v2): keep steered prompts queued until their media intake finishes Materializing a steered prompt's daemon-ref media awaits a file copy during which the active turn may finish. Records are now spliced out of the queue only after that copy completes, and when the turn is gone by enqueue time they are restored to pending so startNext can launch them as fresh prompts — their handles always launch or settle. * fix(agent-core-v2): revalidate the queue and active turn after steer media intake The daemon-ref copy yields, so settle/abort can consume selected records and the active turn can rotate meanwhile. Only records still pending are steered, and only into the turn that was active at entry; records that vanish from the queue are left to their own launch path, and a missing turn restores them to pending instead of splicing an unrelated tail prompt. The intake/queue-preservation contract is documented in the module header. * fix(agent-core-v2): steer only the surviving records and keep their media truthful - The steered content is rebuilt from the records that are still pending after the media intake, so an aborted or concurrently consumed record's text is never injected (or injected twice) alongside the surviving handles. - The enqueue is wrapped so an activeTurnOnly rejection restores the records to pending (the loop throws instead of resolving a missing turn, which made the previous rollback unreachable). - The merged origin now carries the union of every record's bundled skillActivations, and prompt.steered publishes the caller-only content, so the skill instructions reach the model with their metadata intact while the event projection stops leaking internal skill markdown. * fix(agent-core-v2): harden steer rollback and register bundled prompt ids * fix(agent-core-v2): strip bundled blocks from prompt.queued and reject partial steers * fix(kap-server): update session metadata for bundled prompts routed to subagents * fix(agent-core-v2): restart queue after raced steer rollback and prefix skill blocks in merged steer * fix(agent-core-v2): block queue advancement during steer admission * chore: drop the changeset for server-only protocol plumbing |
||
|---|---|---|
| .agents/skills | ||
| .changeset | ||
| .github | ||
| apps | ||
| build | ||
| docs | ||
| packages | ||
| plugins | ||
| scripts | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .npmrc | ||
| .nvmrc | ||
| .oxfmtrc.json | ||
| .oxlintrc.json | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| flake.lock | ||
| flake.nix | ||
| GOAL.md | ||
| LICENSE | ||
| Makefile | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| README.md | ||
| README.zh-CN.md | ||
| SECURITY.md | ||
| tsconfig.json | ||
| vitest.config.ts | ||
Kimi Code CLI
Documentation · Issues · 中文
What is Kimi Code CLI
Kimi Code CLI is an AI coding agent that runs in your terminal — it can read and edit code, run shell commands, search files, fetch web pages, and choose the next step based on the feedback it receives. It works out of the box with Moonshot AI’s Kimi models and can also be configured to use other compatible providers.
Install
Install with the official script. No Node.js required.
- macOS or Linux:
curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash
- Windows (PowerShell):
irm https://code.kimi.com/kimi-code/install.ps1 | iex
On Windows, install Git for Windows before first launch because Kimi Code CLI uses the bundled Git Bash as its shell environment. If Git Bash is installed in a custom location, set
KIMI_SHELL_PATHto the absolute path ofbash.exe.
Then, run it with a new shell session:
kimi --version
For npm install, upgrade, uninstall, see Getting Started.
Quick Start
Open a project and start the interactive UI:
cd your-project
kimi
On first launch, run /login inside Kimi Code CLI and choose either Kimi Code OAuth or a Moonshot AI Open Platform API key. After login, try your first task:
Take a look at this project and explain its main directories.
Key Features
- Single-binary distribution. Install with one command: no Node.js setup, PATH gymnastics, or global module conflicts.
- Blazing-fast startup. The TUI is ready in milliseconds, so starting a session never feels heavy.
- Purpose-built TUI. A carefully tuned interface, optimized end to end for long, focused agent sessions.
- Video input. Drop a screen recording or demo clip into the chat and let the agent watch what is hard to describe in words — turn a reference clip into a LUT, a long video into a short, a screen recording into working code, and more.
- AI-native MCP configuration. Add, edit, and authenticate Model Context Protocol servers conversationally with
/mcp-config, without hand-editing JSON. - Rich plugin ecosystem. Install skills, MCP servers, and data sources from the marketplace or any GitHub repo, with each install's trust level surfaced up front.
- Subagents for focused, parallel work. Dispatch built-in
coder,explore, andplansubagents in isolated contexts while keeping the main conversation clean. - Lifecycle hooks. Run local commands at key points to gate risky tool calls, audit decisions, trigger desktop notifications, or connect to your own automation.
- Editor & IDE integration (ACP). Drive a Kimi Code CLI session straight from Zed, JetBrains, or any Agent Client Protocol client with
kimi acp.
Use it in your editor (ACP)
Kimi Code CLI speaks the Agent Client Protocol, so ACP-compatible editors and IDEs (Zed, JetBrains, …) can drive a session over stdio. Log in once, then point your editor at the kimi acp subcommand — no extra login needed.
For Zed, add this to ~/.config/zed/settings.json:
{
"agent_servers": {
"Kimi Code CLI": {
"type": "custom",
"command": "kimi",
"args": ["acp"],
"env": {}
}
}
}
Then open a new conversation in Zed's Agent panel. See Using in IDEs for JetBrains setup and troubleshooting, and the kimi acp reference for the full capability matrix.
Docs
- Getting Started
- Interaction and approvals
- Sessions
- Using in IDEs (ACP)
- Configuration
- Command reference
Develop
Requirements: Node.js ≥ 24.15.0, pnpm 10.33.0.
git clone https://github.com/MoonshotAI/kimi-code.git
cd kimi-code
pnpm install
pnpm dev:cli # run the CLI in dev mode
pnpm test # run tests
pnpm typecheck # TypeScript check
pnpm lint # oxlint
pnpm build # build all packages
See CONTRIBUTING.md for the full contribution guide.
Community
- Issues
- For security vulnerabilities, see SECURITY.md.
Acknowledgements
Our TUI is built on top of pi-tui. We thank the authors of pi-tui for their valuable work.
License
Released under the MIT License.
