* fix(agent-core-v2): cache workspace alias resolution across calls resolveAliasIds re-read the workspace catalog and the whole session index from disk on every call, so the by_workspace grouping loop and the per-workspace session counts paid repeated full-file reads per workspace per request (~2.4s per 50-group page at 1.1k workspaces, 23 pages serially during a client startup drain). Cache both files as precomputed snapshots (by-id map plus a root-key -> alias ids index) invalidated by the storage watch events, which cover atomic rewrites and cross-process writes; storage backends without watch fall back to reading through. The first resolution primes the workspace merge via IWorkspaceService.list() so the cached catalog matches what WorkspaceService.get() would have returned. * chore: drop the changeset; the user-facing entry ships with the app changelog * fix(agent-core-v2): coalesce cold alias snapshot loads and guard publication Concurrent cold resolveAliasIds callers (the /workspaces route fans out per-workspace counts with Promise.all) all passed the cache check before any caller finished loading, re-running the full catalog and session index reads the cache exists to avoid; memoize the in-flight load promise so a cold batch shares one read. Also capture the invalidation generation before each read and publish the snapshot only when it is unchanged, so a mid-read file replacement cannot leave a stale snapshot installed over the watch invalidation. * fix(agent-core-v2): publish catalog invalidation through the persistence owner A debounced fs watch was the only invalidation channel for the alias catalog snapshot, so an in-process catalog write stayed invisible to resolveAliasIds for up to the watch debounce window while the previous read-through code observed every completed write immediately. IWorkspacePersistence now exposes onDidChange: FileWorkspacePersistence fires it synchronously on save and re-fires the underlying document watch (covering atomic rewrites and cross-process writers), and the aliases service subscribes to it instead of watching raw storage keys. The session index snapshot keeps the filesystem watch, matching the read-side ownership of that file. * fix(agent-core-v2): invalidate session alias snapshots on append-log writes A flushed session_index.jsonl append was invisible to resolveAliasIds for up to the fs-watch debounce window, so a sessions request issued right after a session create could resolve the workspace's aliases from the pre-append snapshot. IAppendLogStore now publishes onDidWrite after each durable flush (append batches and rewrites), and the aliases service drops its session-index snapshot through that event; the raw filesystem watch stays as the channel for cross-process writers. * fix(agent-core-v2): fire append-log write events only after actual writes Once a key has a LogState, every global flush() (WireService flushes after ordinary agent persistence) completed it successfully and fired onDidWrite unconditionally, so idle agent activity kept dropping the alias session-index snapshot and forced full re-reads of an unchanged index. drain() now reports whether it appended anything and the write event fires only when a flush actually persisted a batch or a rewrite. * fix(agent-core-v2): retry shared snapshot loads that span a write Callers joining an in-flight single-flight load after a completed write still received the pre-write snapshot: the generation check only guarded cache publication, not the value returned to awaiters. Each load now carries the generation it started at, and catalog()/sessionIndex() re-read (coalesced through the same single-flight) when the settled load's generation is stale. * fix(agent-core-v2): report partial progress when an append-log drain fails A drain that persisted one batch and then failed the next threw without recording the durable write, so onDidWrite never fired for records that were in fact persisted (the alias session-index snapshot then missed its synchronous invalidation). The write box now threads through the whole owned flush: each successful batch marks it, and the event fires before the failure propagates. * fix(agent-core-v2): retry the whole alias resolution across a mid-write The per-snapshot retry guarded each read on its own, so a write landing between the catalog and session-index reads returned an alias set assembled across two generations. resolveAliasIds now captures the generation once, reads both snapshots together, and retries the whole resolution when either input was invalidated mid-flight. The spanned-write test is reworked to gate after the load (so the snapshot content genuinely predates the write), and a new case covers the cross-generation mix directly. * fix(agent-core-v2): replace the session-index fs watch with a size check A resident chokidar watcher per server on the shared home directory degraded watch delivery for unrelated files under test-suite boot volume (the prompts suite lost the config.toml reload race and the catalog missed a just-written model). In-process appends were already covered synchronously by the append-log write event; cross-process writers now surface through a per-call size comparison on the append-only file, which costs one stat per resolve and needs no resident watcher. |
||
|---|---|---|
| .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 | ||
| CONTRIBUTING.zh-CN.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.
