daemon-backend-kimicode

# Kimi Code Daemon Backend — Flag Discovery Entrypoint The installed CLI's own help is the authority for Kimi Code flags; this page is only the entrypoint. Conversion rules, key safety, and persistence live in the parent [`reference/cli-backends/SKILL.md`](../../../SKILL.md). `kimi` is the accepted short alias; persisted daemon entries use the canonical backend name `kimicode`. ## Discover flags from the installed CLI 1. Run, in bash: `kimi --version` and `kimi --help`. The daemon backend wraps the top-level one-shot mode (`kimi --prompt <prompt> --output-format text`), so the top-level help is the relevant flag surface — there is no `exec`-style wrapper subcommand. Run `kimi <subcommand> --help` only when a task actually needs one of the listed subcommands. These are local read-only commands; no session is started. 2. Translate what you found into `backend_options` with the parent's generic conversion rules. Nothing Kimi-specific is added to that contract here. Flag-name note: the output switch is `--output-format` (`text` / `stream-json`), not `--format`. ## Example: model selection `kimi --help` lists `-m, --model <model>` for per-invocation model choice. Through `backend_options`, a string value becomes `--flag <value>`: ```jsonc { "backend": "kimicode", // or the accepted alias "kimi" "tasks": [{ "task": "Implement and validate the change.", "tools": [], "backend_options": { "model": "kimi-for-coding" } }] } // argv: kimi --model kimi-for-coding --prompt <prompt> --output-format text ``` The model vocabulary belongs to the installed CLI and its provider configuration — LingTai does not validate, enumerate, or simulate model names. ## Subscription & auth Moonshot AI keys: `KIMICODE_API_KEY` / `KIMI_API_KEY` / `MOONSHOT_API_KEY` map to `KIMI_MODEL_API_KEY` only when unset. Never print key values. Official docs: https://github.com/MoonshotAI/kimi-code ## Harness boundary Kimi Code declares a reserved-flag list at the validation layer; passing any of these in `backend_options` refuses the whole batch before spawn: `--prompt` / `-p`, `--output-format`, `--yolo` / `-y`, `--session` / `-S`, `--continue` / `-c`. LingTai owns `--prompt` and `--output-format` (they drive the non-interactive text-capture harness), forbids `--yolo` (the CLI refuses `--prompt` combined with `--yolo`), and reserves the session/continue flags because resume is not wired for this backend: no stable machine-readable session-id output was verified, so `daemon(action="ask", input={"id": ..., "message": ...})` returns an explicit unsupported-backend error — start a new kimicode emanation instead. Free-form options are inserted between `kimi` and the owned flags (the prompt travels via `--prompt`, never as a trailing positional). Output is plain text, not a JSON event stream: stdout is recorded verbatim, line by line, as `cli_output` events, no session id is captured, and the joined stdout becomes the result. The run-private MCP loader is not argv-based — the daemon writes `daemon_common` plus parent stdio and HTTP registrations to `<run>/kimi-code-home/mcp.json` (path recorded in `daemon.json` under `backend_harness_files.kimicode_mcp_config`); secret env/header values stay out of prompts and logs. The CLI's own MCP declaration search paths are `$KIMI_CODE_HOME/mcp.json`, project-root `.mcp.json`, and cwd-local `.kimi-code/mcp.json`; the schema accepts `stdio` and `http` transports — SSE is not exposed by LingTai daemon task registrations. ## Kimi-specific validation steps In the Generic validation checklist (see `reference/cli-backends/SKILL.md`), additionally confirm from installed help that `--yolo` conflicts with `--prompt` (the CLI refuses that pairing). Before enabling `ask` for this backend, source-cite a stable machine-readable session-id output plus a tested resume command from local help/code — do not guess.