Kimi profile still describes archived Python kimi-cli; current Kimi Code shares the kimi executable but uses a different runtime and config root #154

Observed on 2026-10-23 while installing the terminal clients listed by LocalSetup 4.57.0. Installed framework source commit: 5d07ed278ed4c2030488013abbb1212de6e89844. The relevant definition was also checked on repository main and is still present.

LocalSetup definition

• clients.yaml, kimi-cli profile marks kimi-cli supported with an active integration lifecycle, executable kimi, and global configuration ~/.kimi/config.toml. Its research date is 2026-09-06 and its sources are the Python MoonshotAI/kimi-cli implementation.
• CLIENT_INTEGRATION_METADATA.md, Kimi CLI documents that implementation's loader, configuration and skill-root masking rules. Host qualification is explicitly not-run.

Observable upstream and installed-client evidence

1. The upstream kimi-cli getting-started page says the project is archived, no longer maintained, and directs users to Kimi Code CLI. GitHub shows the repository was archived on 2026-09-23.
2. Current installation guidance distributes the successor as @moonshot-ai/kimi-code on Node.js. The migration guide explicitly describes the Python/uv-to-Node.js change.
3. An isolated Bun installation of @moonshot-ai/kimi-code@2.3.0 completed successfully on Linux x86_64 with Node 24.22.1 and Bun 1.4.4. Its installed package metadata is:

   {"name":"@moonshot-ai/kimi-code","version":"2.3.0","bin":{"kimi":"dist/main.mjs"},"engines":{"node":">=22.19.0"}}

   The executable returned 2.3.0 from --version, exit 0.
4. Current configuration documentation puts the successor's configuration at ~/.kimi-code/config.toml, relocated by KIMI_CODE_HOME. That differs from the profile's ~/.kimi/config.toml.

Reproduction and impact

Inspect the linked profile and upstream pages, then inspect package.json from the pinned successor package and run its kimi --version in a disposable home. The old and new products share the same executable name, so presence of kimi alone cannot identify which implementation the old filesystem qualification applies to. Following current official install guidance obtains the successor, while the active profile still describes the archived implementation.

Please record the legacy lifecycle and distinguish the successor's package/runtime/configuration contract. Qualify its discovery and skill precedence independently before transferring the legacy adapter claims. The existing ls/tests/test_kimi_prerequisite.py fixtures describe the old implementation and are a relevant starting point.

Validation here covered package installation, package metadata and version startup only. No migration, login, provider request, skill activation, or successor adapter qualification was performed; existing user data was preserved.