What
Add Kimi Code CLI (Moonshot AI) as a first-class provider — or, more generally, add a "custom ACP agent" slot where users can register any ACP-compatible CLI by name + command. (Related: #963 requests the same for Google Antigravity CLI + custom binary path; a generic slot would cover both.)
Why this should be low-effort
Kimi Code CLI natively implements ACP over stdio via a dedicated subcommand:
kimi acp # ACP server over stdin/stdout, JSON-RPC
kimi acp --login # device-code login flow for terminal auth
This matches the spawn shape Claudian already uses for OpenCode (<command> acp --cwd=<vault>). From the official ACP reference, the adapter implements the full normal agent flow:
initialize, authenticate (authMethods includes login; existing CLI OAuth sessions are reused)session/new, session/load, session/resume, session/prompt, session/cancel, session/listsession/set_config_option (model / thinking / mode pickers) and session/set_model- Client reverse-RPC:
session/update (message chunks, tool calls, plans), session/request_permission, fs/read_text_file, fs/write_text_file
- MCP forwarding (
http / sse / stdio) from client-provided mcpServers
What I tried (and where it broke)
On Windows 11, I pointed the OpenCode provider's CLI path at the locally installed kimi (C:\Users\<user>\Documents\.npm-global\kimi.cmd, kimi-code 0.29.1) and enabled it. The session failed to start (no detailed error surfaced in the UI, so I can't quote one — sorry).
Likely culprit worth checking: on Windows, npm-installed CLIs are .cmd shims, and Node's child_process.spawn cannot execute .cmd files without shell: true since the CVE-2024-27980 fix (EINVAL). A first-class provider could handle Windows shim resolution explicitly (spawn cmd.exe /c kimi.cmd acp ... or use shell: true on win32), the same way Claude Code's own path resolution is handled.
Environment
- Claudian 2.0.39
- Obsidian on Windows 11
- kimi-code 0.29.1 (
kimi acp --help verified present; kimi OAuth login already active on this machine)
Happy to test any build or provide ACP handshake logs (~/.kimi-code/logs/) if useful.
What
Add Kimi Code CLI (Moonshot AI) as a first-class provider — or, more generally, add a "custom ACP agent" slot where users can register any ACP-compatible CLI by name + command. (Related: #963 requests the same for Google Antigravity CLI + custom binary path; a generic slot would cover both.)
Why this should be low-effort
Kimi Code CLI natively implements ACP over stdio via a dedicated subcommand:
This matches the spawn shape Claudian already uses for OpenCode (
<command> acp --cwd=<vault>). From the official ACP reference, the adapter implements the full normal agent flow:initialize,authenticate(authMethods includeslogin; existing CLI OAuth sessions are reused)session/new,session/load,session/resume,session/prompt,session/cancel,session/listsession/set_config_option(model / thinking / mode pickers) andsession/set_modelsession/update(message chunks, tool calls, plans),session/request_permission,fs/read_text_file,fs/write_text_filehttp/sse/stdio) from client-providedmcpServersWhat I tried (and where it broke)
On Windows 11, I pointed the OpenCode provider's CLI path at the locally installed
kimi(C:\Users\<user>\Documents\.npm-global\kimi.cmd, kimi-code 0.29.1) and enabled it. The session failed to start (no detailed error surfaced in the UI, so I can't quote one — sorry).Likely culprit worth checking: on Windows, npm-installed CLIs are
.cmdshims, and Node'schild_process.spawncannot execute.cmdfiles withoutshell: truesince the CVE-2024-27980 fix (EINVAL). A first-class provider could handle Windows shim resolution explicitly (spawncmd.exe /c kimi.cmd acp ...or useshell: trueon win32), the same way Claude Code's own path resolution is handled.Environment
kimi acp --helpverified present;kimiOAuth login already active on this machine)Happy to test any build or provide ACP handshake logs (
~/.kimi-code/logs/) if useful.