Kimi CLI is archived: what the Python agent did, and how to move to Kimi Code CLI

Version 1.52.0 is the last build, and installed copies will stop working

The MoonshotAI/kimi-cli repository is archived. The final release, 1.52.0, landed on 2026-09-22, the same day as the last push, following 1.51.0 on 2026-09-21 and 1.50.0 on 2026-09-01. The project's own notice is blunt: no further releases, bug fixes or security updates, and existing installations are no longer supported and will stop working. The pyproject.toml carries the classifier Development Status :: 7 - Inactive, and its description now reads "[Archived] Legacy Python Kimi CLI, no longer maintained." Issues, feature requests and security reports now go to the MoonshotAI/kimi-code repository instead. For anyone still running the Python tool, the consequence is that a failure tomorrow will not be fixed here; the only supported path forward is the replacement, Kimi Code CLI, built by the same team. The source stays available under the Apache License 2.0, so forking remains legally possible, but a fork would inherit every unfixed issue from this point on.

The kimi-code package on PyPI is not the new Kimi Code CLI

This repository published five packages to PyPI, and all of them are archived with it: kimi-cli, kimi-code, kosong, pykaos and kimi-sdk. Published versions stay downloadable but receive no updates. The confusing one is kimi-code. On PyPI it is a legacy alias of kimi-cli, not the next-generation Kimi Code CLI. Running a Python package install for kimi-code therefore puts the archived agent back on your machine under a name that looks current. The new tool is distributed through an install script, Homebrew as kimi-code, and npm as @moonshot-ai/kimi-code. If a teammate reports that their fresh Kimi Code install still behaves like the old one, the PyPI alias is the first thing to check. The same caution applies to kosong and pykaos: the legacy pyproject.toml pins kosong[contrib]==0.56.0 and pykaos==0.9.0, and neither will see another release from this repository.

Installing the replacement on macOS, Linux and Windows

Kimi Code CLI ships with a shell installer for macOS and Linux:

# macOS / Linux
curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

On Windows the installer is a PowerShell one-liner:

# Windows (PowerShell)
irm https://code.kimi.com/kimi-code/install.ps1 | iex

Both pipe a remote script straight into a shell, so read the script first if your environment forbids that pattern. The alternatives avoid piping: brew install kimi-code on Homebrew, or npm install -g @moonshot-ai/kimi-code on npm. After installing, open a new terminal before running kimi, so the shell picks up the new binary rather than a cached path to the old one. For comparison, the legacy Python package declared requires-python >=3.12, so the old tool and the new one come from entirely different distribution channels.

kimi migrate copies sessions and MCP servers but not logins or plugins

On first launch, Kimi Code CLI looks for legacy data in ~/.kimi/ and offers to import it. You can trigger the same import later with kimi migrate. What comes across: your config, your MCP server definitions, input history and sessions. The original files in ~/.kimi/ are never modified or deleted, so a failed import can be retried. What does not come across is the part that breaks workflows quietly. Login credentials are not migrated, so you must run /login again. MCP authorizations are not migrated, so every OAuth-backed server has to be re-authorized even though its definition was imported. Kimi CLI plugins are not migrated at all. A user who relied on a custom plugin will open the new CLI, see their sessions and servers, and only discover the missing plugin when a command fails. Inventory plugins before you uninstall anything. Once you are satisfied, remove the old tool with uv tool uninstall kimi-cli or brew uninstall kimi-cli, depending on how it was installed.

MCP servers were managed with the kimi mcp subcommands

The legacy CLI managed MCP servers through a kimi mcp command group covering streamable HTTP, HTTP with OAuth, and stdio transports:

# Add streamable HTTP server:
kimi mcp add --transport http context7 https://mcp.context7.com/mcp --header "CONTEXT7_API_KEY: ctx7sk-your-key"

# Add streamable HTTP server with OAuth authorization:
kimi mcp add --transport http --auth oauth linear https://mcp.linear.app/mcp

# Add stdio server:
kimi mcp add --transport stdio chrome-devtools -- npx chrome-devtools-mcp@latest

# List added MCP servers:
kimi mcp list

# Remove an MCP server:
kimi mcp remove chrome-devtools

# Authorize an MCP server:
kimi mcp auth linear

It also accepted an ad-hoc file in the common mcpServers JSON format through kimi --mcp-config-file /path/to/mcp.json. That distinction matters during migration. Servers added with kimi mcp add live in ~/.kimi/ and are imported, minus their authorizations. Servers you only ever passed with --mcp-config-file were never stored, so the file on disk is your only copy; keep it.

ACP editor configs point at a command name the new CLI now owns

Kimi CLI spoke the Agent Client Protocol, pinned at agent-client-protocol==0.8.0. After logging in once in a terminal, you configured Zed or a JetBrains IDE to launch it as an agent server with kimi acp, using ~/.config/zed/settings.json or ~/.jetbrains/acp.json:

{
  "agent_servers": {
    "Kimi CLI": {
      "type": "custom",
      "command": "kimi",
      "args": ["acp"],
      "env": {}
    }
  }
}

That config calls whatever binary answers to kimi on your PATH. Kimi Code CLI is also launched as kimi, so after migration the editor will start the new tool with the acp argument. Whether it accepts that argument in the same way is a question for the Kimi Code CLI docs; confirm it before you uninstall the legacy package, or the IDE agent panel will fail to start its threads. The same applies to the Kimi Code VS Code extension, which the legacy CLI integrated with.

Ctrl-X shell mode never supported cd

One legacy feature that set Kimi CLI apart was a shell command mode toggled with Ctrl-X, letting you run commands without leaving the agent. It had a documented gap: built-in shell commands such as cd were not supported. A companion Zsh plugin brought the same Ctrl-X switch into Zsh itself:

git clone https://github.com/MoonshotAI/zsh-kimi-cli.git \
  ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/kimi-cli

followed by adding kimi-cli to the plugins list in ~/.zshrc and restarting Zsh. Users of other plugin managers were sent to the plugin's own README. If you still have that plugin loaded, remember it was written for the archived agent; it is a separate repository, and its behaviour against Kimi Code CLI is not covered by the archive notice, so test the Ctrl-X binding after migrating rather than assuming it carries over.

The repository still has value as a reference for building agents

Even archived, the codebase shows how a Python terminal agent was put together. The examples/ directory holds custom souls (custom-echo-soul, custom-kimi-soul), custom-tools, a sample-plugin, kimi-psql, and two examples of the wire format, kimi-cli-stream-json and kimi-cli-wire-messages. The Makefile wires a web backend served by uvicorn on port 5494 and a vis backend on port 5495, each with a Vite frontend, and make prepare runs uv sync --frozen --all-extras --all-packages plus prek git hooks. Dependencies are pinned tightly, including fastmcp==3.2.4, pydantic==2.12.5 and prompt-toolkit==3.0.52. Reading this code is fine; shipping it is not, since none of those pins will be bumped for future security issues.

Editorial conclusion

Nobody should start a new setup on the Python Kimi CLI: the repository is read-only, it gets no security fixes, and installed copies are slated to stop working. Current users should install Kimi Code CLI with the official script, Homebrew or npm, let kimi migrate import ~/.kimi/, then redo /login and every MCP authorization. Before deleting the old tool, check that your plugins and any ACP editor configuration still work under the new binary, because plugins are not migrated.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes