bug: Kimi Code (code.kimi.com) is not detected: the --version signature only matches MoonshotAI/kimi-cli

[theeasypet]

What happened?

Summary

Chorus fails to detect Kimi Code (the agentic coding CLI from code.kimi.com, installed to ~/.kimi-code). Even though the binary is named kimi, is on PATH, and runs cleanly, chorus init reports Kimi CLI ... not detected and omits kimi from the AI CLIs ready: list.

Root cause: the reviewer-CLI detector verifies kimi --version output against the signature /\bkimi\b/i, which requires the literal word "kimi" in the output. Kimi Code prints a bare semver (0.6.0) with no name token, so it is rejected. The signature appears to have been written for MoonshotAI/kimi-cli, which is a different CLI than Kimi Code despite sharing the kimi binary name and vendor (Moonshot).

Environment

• chorus: 0.8.60 (npm global, prefix ~/.npm-global)
• OS: macOS (Darwin), zsh
• Kimi Code: 0.6.0, installed via curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash (from https://www.kimi.com/code)
  • install dir: ~/.kimi-code/bin/kimi (Mach-O executable)
  • on PATH via ~/.zshrc

Background: there are two different kimi CLIs

This is the crux of the issue. Both are Moonshot products, both install a binary named kimi, but they are different programs with different --version output (and likely different invocation interfaces):

	MoonshotAI/kimi-cli	Kimi Code
Source	https://github.com/MoonshotAI/kimi-cli (linked in chorus init.js)	https://www.kimi.com/code, code.kimi.com/kimi-code/install.sh
Install dir	varies	~/.kimi-code/
Binary name	kimi	kimi
kimi --version	output contains "kimi" (what the signature expects)	bare semver, e.g. 0.6.0
kimi --help tagline	-	The Starting Point for Next-Gen Agents

Chorus's detector is written for the first; in the wild, users installing from kimi.com get the second.

Root cause

dist/lib/cli-detect.js:

const STARTS_WITH_VERSION = /^\s*\d+\.\d+/;
const CLI_SIGNATURES = {
    'claude-code': /\bclaude\b/i,
    'codex-cli': /\bcodex\b/i,
    'gemini-cli': STARTS_WITH_VERSION,   // bare version accepted
    'opencode-cli': STARTS_WITH_VERSION, // bare version accepted
    'kimi-cli': /\bkimi\b/i,             // <-- requires "kimi" in output
    'grok-cli': /\bgrok\b/i,
    'antigravity-cli': STARTS_WITH_VERSION, // bare version accepted
};

The detector already has a basenameMatches() allowlist that requires the resolved binary to be named kimi before the version check runs, and gemini-cli, opencode-cli, and antigravity-cli all rely on that allowlist while accepting a bare-semver --version via STARTS_WITH_VERSION. Kimi is the outlier that still demands a name token, which is exactly what Kimi Code does not emit.

Reproduction

1. Install Kimi Code: curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash
2. Confirm it works: kimi --version -> 0.6.0
3. chorus init

Observed:

○ Kimi CLI      not detected
✓ AI CLIs ready: claude, codex, gemini, opencode, agy

Expected vs actual

• Expected: a binary named kimi that runs and reports a version is detected as a reviewer CLI.
• Actual: Kimi Code is rejected purely because its --version string is a bare semver.

Proposed fix

Relax the kimi signature to also accept a bare semver, mirroring gemini-cli / opencode-cli / antigravity-cli. The basenameMatches() allowlist already gates on the binary being named kimi, so this does not loosen the name guard:

-    'kimi-cli': /\bkimi\b/i,
+    // Kimi Code (code.kimi.com) prints a bare semver ("0.6.0") with no name
+    // token, unlike MoonshotAI/kimi-cli. Accept either a "kimi" token OR a bare
+    // version; the basename allowlist still gates on the binary being named `kimi`.
+    'kimi-cli': /\bkimi\b|^\s*v?\d+\.\d+/i,

I have applied this locally and Kimi Code is now correctly listed under AI CLIs ready:.

Secondary concern (worth a maintainer decision)

Detection is only half the story. Because Kimi Code and MoonshotAI/kimi-cli are different programs, their non-interactive / headless invocation interfaces likely differ. Once detected, Chorus will dispatch to kimi using the arguments it expects for one of them, which may not match the other. It would help users to know which Kimi CLI Chorus officially targets, or to support both (the ~/.kimi-code install dir could also be added to the per-CLI fallback paths in fallbackPaths(), which currently only probes ~/.kimi/bin).

Related

- 32 (Validation failed: gemini.cmd --version exited null.) - same --version validation subsystem, different CLI.

Output of chorus doctor

▶ Chorus doctor

  CLI detection

    ✓ claude     /Users/ericcovarrubias/.local/bin/claude (PATH)
    ✓ codex      /Users/ericcovarrubias/.npm-global/bin/codex (PATH)
    ✓ gemini     /Users/ericcovarrubias/.npm-global/bin/gemini (PATH)
    ✓ opencode   /usr/local/bin/opencode (PATH)
    ✓ kimi       /Users/ericcovarrubias/.kimi-code/bin/kimi (PATH)
    ✗ grok       not found
    ✓ agy        /Users/ericcovarrubias/.local/bin/agy (PATH)

  PATH visibility

    daemon PATH:      17 dirs (/Users/ericcovarrubias/.npm-global/bin:/Users/ericcovarrubias/.kimi-code/bin:/Us…)
    captured shell:   25 dirs (Restored session: Sat May 30 12:01:58 EDT 2026
/Users/ericcovarrubias/.npm-globa…)

    ! 4 dirs in your shell PATH but NOT in the daemon's PATH:
      Restored session
       Sat May 30 12
      01
      58 EDT 2026
/Users/ericcovarrubias/.npm-global/bin

    Tip: restart the daemon with chorus stop && chorus start to re-capture.

Chorus version

v0.8.60

Operating system

macOS

Node version

v24.14.1

Logs / errors

Prerequisites

• I searched existing issues for duplicates
• I'm running the latest published version (or main)

[chorus-codes]

Fixed in v0.8.61 (npm i -g chorus-codes@0.8.61) via #99.

Thanks for the unusually thorough writeup — the "two different kimi builds" framing was exactly right, and the table made the root cause obvious. A few notes on what shipped:

• Detection — relaxed the kimi-cli signature to accept a bare semver, as you proposed. The basename allowlist still gates on the binary being named kimi, so it's as safe as the existing gemini/opencode matchers.
• Fallback path — ~/.kimi-code/bin is now probed alongside ~/.kimi/bin, so the native build is found even when it's not on PATH.
• Transport (the part beyond detection) — your "secondary concern" was the real trap. On its own, the regex relax would have made a Kimi-Code-only user detected but broken: with no ~/.kimi/config.toml, the shim fell through to the opencode-go path and would either fail (no OpenCode Go sub) or silently ignore your kimi install. v0.8.61 now drives the kimi binary directly when ~/.kimi-code is present. The two builds share the same kimi --print --output-format stream-json headless interface (confirmed against the code.kimi.com docs), so this stays one lineage — no new config needed.

One thing I couldn't verify here (the native binary isn't installed on my dev box): chorus passes -m <model> to the kimi binary. The legacy Python build accepts it; if native Kimi Code v0.6.0 rejects -m, a kimi review could still fail even though detection now works. Could you run a quick review with kimi as a reviewer and confirm it completes end-to-end? If -m is the problem, the follow-up is a one-liner (omit the flag for the native transport and let your logged-in account default apply).

[chorus-codes]

Two follow-up hardenings to the original fix are now live in v0.8.62 (npm i -g chorus-codes@0.8.62):

• fix(kimi): key transport on the resolved binary, not ~/.kimi-code existence #101 — the transport selector now keys on which kimi binary actually runs (realpath-resolved, both sides), not on the mere existence of a ~/.kimi-code dir. This fixes a dual-install edge: if you had both the native and the legacy Python builds and PATH resolved to an unconfigured Python kimi, the old logic drove it directly → "LLM not set". Now it correctly falls back.
• fix(runtime-path): add ~/.kimi-code/bin + ~/.grok/bin to spawn PATH (#98) #102 — ~/.kimi-code/bin (and ~/.grok/bin) are now on the daemon's spawn PATH, so a native install in its dot-dir that isn't on your shell PATH no longer ENOENTs after being detected.

A deeper structural item (spawn the detected absolute path instead of the bare binary name, to eliminate any detection/spawn PATH-ordering mismatch) is tracked separately in #104.

Still keen on your verification of the original report: does a review with kimi as a reviewer complete end-to-end on v0.8.62? That's the one thing I couldn't test locally (the native binary isn't installed on my dev box), specifically whether native Kimi Code v0.6.0 accepts the -m <model> flag chorus passes. Thanks again for the excellent report.