kimi provider: automation prompt never delivered (stdin-after-start misses; --quiet flag unknown in kimi 2.1.1) — run silently completes as no-op #28005

Summary

On Orca 1.4.183 (macOS, Apple Silicon), automations created with --provider kimi spawn a Kimi Code TUI but the automation prompt is never delivered. The session sits at an empty prompt, does nothing, exits ~7 minutes later, and the run is marked completed in the Automations panel — a silent no-op reported as success.

Environment

• Orca 1.4.183
• kimi-code 2.1.1 (kimi on PATH)
• macOS 26 (Apple Silicon)

Repro

orca automations create --name test --trigger daily --time 09:05 \
  --prompt "Reply with the word OK" --provider kimi \
  --project-host-setup <id> --fresh-session
orca automations run <id>

Observe the spawned terminal session: Kimi Code welcome banner, empty input box, prompt text never appears. orca automations runs --id <id> --json → status: completed, error: null, output snapshot = TUI banner only.

Evidence

1. Daemon log (~/Library/Application Support/orca/logs/daemon.log): the run's session gets a startup-command-delivery with commandLength: 4 (just kimi), then session-created, then ~7 min later session-exited code 0 + session-killed. No prompt-delivery event exists for the session.
2. App bundle (app.asar) contains two kimi delivery definitions, both incompatible with kimi-code 2.1.1:
   • terminal spawn: kimi: { detectCmd: "kimi", promptInjectionMode: "stdin-after-start" } — the stdin injection never lands in the 2.1.1 TUI (empty input box).
   • headless: buildArgs: ({prompt, model, thinkingLevel}) => ["--prompt", prompt, "--quiet", ...] — --quiet does not exist in kimi-code 2.1.1 (kimi --help has no such flag; it hard-exits).
3. Interactive kimi sessions inside Orca work fine — because the user types the prompt. Only machine-delivered prompts fail.

Related

The same --quiet incompatibility breaks Orca's sourceControlAi kimi calls; I've been working around those locally with a flag-sanitizing shim since August. So both kimi invocation paths in current Orca appear to target an older kimi CLI contract.

Expected

Automation prompt is delivered to the kimi session (or the run fails loudly instead of completing as a no-op).