Repository navigation
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
Description
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 (
kimion 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
- Daemon log (
~/Library/Application Support/orca/logs/daemon.log): the run's session gets astartup-command-deliverywithcommandLength: 4(justkimi), thensession-created, then ~7 min latersession-exited code 0+session-killed. No prompt-delivery event exists for the session. - 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", ...]—--quietdoes not exist in kimi-code 2.1.1 (kimi --helphas no such flag; it hard-exits).
- terminal spawn:
- 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).
Activity
wowlegend commentedon Oct 12, 2026
Retested on v1.4.224 (macOS arm64, kimi-code 2.1.1,
orca automations runwith--provider kimi --fresh-session): still broken.Evidence on the latest build: the daemon log shows
startup-command-deliverywithcommandLength: 4(a barekimilaunch), no prompt-delivery event for the session, thensession-exited code 0~7 minutes later — and the run is markedcompletedin the Automations panel despite zero work done.So this persists after #26703 — consistent with that fix covering the server-run existing-workspace path while the local fresh-session
stdin-after-startpath still misses.--quietalso remains in the kimi spec on main (src/shared/commit-message-agent-specs-secondary.ts:90as of 2026-10-12), keeping the headless argv path dead as well.Related but distinct: #24509 / #24689 (CR→LF non-submit) — our case never gets as far as a typed prompt.
AmethystLiang commentedon Oct 12, 2026
Thanks for reporting. Looking into it
wowlegend commentedon Oct 25, 2026
Retested on Orca 1.4.239 with kimi-code 2.3.0/2.3.1 (Kimi auto-updated between runs):
orca automations runon a kimi automation in an existing, trusted workspace with--fresh-session, prompt "Reply with exactly the word PONG and nothing else".Out of 3 runs, the prompt was submitted and answered twice. Once, it landed in the Kimi composer with a trailing blank line and was never submitted. All 3 runs were marked
completed, including the one where nothing ran.So the empty-composer symptom from my original report no longer reproduces. What remains is an intermittent unsubmitted prompt, which matches #24509 (Enter arriving as a newline) and the approach in #24689 (still open). The
--quiethalf of this report was the Source Control AI recipe, fixed by #33285 and shipped in v1.4.240 (#14771). The other remaining problem is that an unsubmitted prompt is reported as a completed run.wowlegend commentedon Oct 25, 2026
Retest on Orca 1.4.240 + kimi-code 2.3.1 (macOS), 2026-10-25, same method as my last comment: a disabled kimi automation (
--fresh-session, existing trusted workspace, prompt "Reply with exactly the word PONG and nothing else, then stop."), run manually, each run waited to a final status and its terminal read afterwards.Result: 11 runs, 11 prompts submitted, 0 left in the composer. 10 answered PONG; on the 11th my script closed the terminal after the prompt was sent but before the reply arrived, so that one shows submission only.
On 1.4.239 (Kimi 2.3.0/2.3.1, it auto-updated mid-test) it was 2 of 3 submitted. Kimi stayed on 2.3.1 for this whole retest, so the change could come from Orca, from Kimi, or from chance.
What this does and does not show: if the 1.4.239 failure rate (about 1 in 3) still held, 11 clean runs in a row would happen about 1% of the time, so that rate looks gone. A lower rate isn't ruled out: at 1 in 10, 11 clean runs still happen about 31% of the time. I only tested a short prompt in an already-trusted workspace. #24689 is still open and isn't in the 1.4.240 notes, so I don't know what changed. I'd keep this open until a maintainer can say whether 1.4.240 changed prompt delivery, or #24689 lands. The other half of my last comment, an unsubmitted prompt being reported as a completed run, didn't come up in these runs, so it is untested here.
wowlegend commentedon Oct 27, 2026
Confirming from the reporter side, and thanks for #33581. On Orca 1.4.242 with kimi-code 2.3.2 (macOS), 3 of 3 manual runs of a disabled kimi automation (--fresh-session, existing trusted workspace, prompt "Reply with exactly the word PONG and nothing else, then stop.") were submitted and answered, as were 14 of 14 earlier runs on 1.4.240 and 1.4.241; the one unsubmitted prompt I saw was on 1.4.239. I read #33581 as the root-cause fix for that class (composer-ready wait plus bracketed paste and a separate Enter, on macOS as well as Windows), and I'll comment again only if a prompt is left in the composer.