kimi-pursue

kimi:pursue

Forward an autonomous goal-mode objective to the shared companion runtime and return the result verbatim. Kimi pursues the objective across continuation turns until it completes, blocks itself, or the --budget expires — each turn write-gated by the same PreToolUse hook + workspace allowlist as rescue.

Runtime instructions

When invoked:

• decide whether the task is genuinely AUTONOMOUS multi-turn pursuit rather than a single bounded delegated task (kimi-rescue) or read-only work (kimi-ask / kimi-review / kimi-swarm); when in doubt, prefer kimi-rescue — pursue is only for explicit hands-off autonomy
• preserve the user's objective and explicit constraints with minimal reframing
• call the shared companion runtime with exactly one Bash invocation: ${CLAUDE_PLUGIN_ROOT}/scripts/companion.sh task pursue <args>
• the companion accepts a strict allowlist of flags: --budget <duration> (HARD wall-clock ceiling; e.g. 30m, 1h, 90s; bare number = minutes; default 45m — the ONLY guaranteed bound on an autonomous run), --turns <N> (SOFT hint injected into the objective so Kimi calls SetGoalBudget itself; advisory, NOT enforced headless), and -m/--model <name>. Everything else is trailing objective text. Kimi's extended reasoning is always on; the parser hard-rejects --thinking/--no-thinking
• do not invent flags. The runtime hard-fails with INVALID_ARGS on unknown flag-shaped tokens — pass -- before flag-shaped objective text to forward it as objective text rather than a flag
• this is the plugin's highest blast radius: write-capable AND autonomous. Only dispatch on explicit user intent for hands-off multi-turn pursuit. Writes are confined to the workspace by the rescue allowlist, and the index-0 PreToolUse hook fires on EVERY continuation turn — proven by a real-binary smoke that runs goal mode under a read-only label and asserts zero files land across the whole multi-turn run (no continuation turn slips past the hook; pursue itself writes via the rescue allowlist). pursue cannot mutate git state (the main thread owns branch/commit). The autonomy is bounded ONLY by --budget, so always pass an explicit one sized to the task and keep it WELL UNDER the 45m default unless the user named a larger window — a model-launched, possibly unwatched write loop should get the smallest budget that can plausibly finish, and never more than the user asked for; never try to remove it
• pursue is foreground-only at the runtime level — --background, --wait, --fresh, and --resume are rejected with INVALID_ARGS (--resume intentionally: goal mode's goalId differs from the resume sessionId). How you make the Bash call is a separate question: default to run_in_background: true. An autonomous goal loop routinely outlives a foreground shell timeout (Claude Code caps foreground Bash at 10 minutes; --budget defaults to 45m), and a blocked foreground call is worse oversight, not better — it freezes you for the whole run, so you cannot report progress or cancel on request. What bounds this surface is the index-0 hook, the workspace allowlist, the no-git-mutation rule, and the mandatory finite --budget — none of which depend on anyone watching. Keep --budget finite and never remove it: it is the sole hard bound on the loop
• the user should never have to type a job id (it is a raw UUID), and you will not have one either — a detached run prints nothing at launch; the job id only reaches you with the final report. So cancel by omitting it: ${CLAUDE_PLUGIN_ROOT}/scripts/companion.sh cancel targets the latest RUNNING job for this repo (findLatestJob({runningOnly:true})), which is the run you just launched. With two runs in flight the no-id form takes the most recent, so confirm which the user means first. Prefer that command over an Esc/interrupt: a harness interrupt gives the companion only ~1.35s before SIGKILL (measured), less than its own teardown needs, so it can die mid-settlement and skip the terminal-state write — the cancel command signals the job from a separate process that is not racing that deadline. (Either way the interrupt reaches the whole process group, so no Kimi child survives to keep writing)
• pursue's edits land in the user's REAL tree and a cancel does not roll them back (unlike kimi-swarm-write, whose edits are confined to a throwaway worktree and come back as a discardable patch). Cancelling stops further work; it does not undo work already done. Say so plainly when you launch one, and prefer a tight --budget over a generous one
• pursue REFUSES without the /kimi:setup PreToolUse hook (like rescue and swarm — an autonomous write loop with no per-turn enforcement is unacceptable). If the companion refuses, surface that and tell the user to run /kimi:setup; do not reach for KIMI_PLUGIN_CC_SKIP_HOOK_CHECK
• requires kimi-code >= 0.8.0 (headless goal mode)
• there is no job id to return at launch. Report the id from the final result so the main thread can use /kimi:status, /kimi:result, or /kimi:replay; for a mid-run stop use the no-id companion.sh cancel above
• /kimi:result <jobId> --json returns a structured envelope with metadata plus the artifact body.