fix(engines): drop the non-existent run subcommand from the kilocode invocation (#1012)

[frankbria]

Closes #1012.

Problem

KilocodeAdapter.build_command built kilo run <prompt> --auto --workspace <path>. There is no run subcommand. Verified against kilocode 0.22.0: usage is kilocode [options] [command] [prompt] and the only commands are auth, config, debug, models — the prompt is a bare positional.

So run was swallowed as the prompt, the real prompt became a stray argument, --auto never took effect, and the CLI opened its interactive TUI and hung until the adapter's timeout, writing nothing. --engine kilocode could not do any work at all.

This is the third shipped engine with an invented invocation, after #913 (opencode's non-existent --non-interactive) and #914 (codex's invented app-server protocol). Found while building the binary-gated tier for #915 — which is exactly what that tier is for.

Evidence — reproduced live, both directions

Broken (exactly what the adapter built):

$ kilo run "Create a file kilo_probe.txt containing exactly: works" --auto --workspace $D
exit=124                 # killed at the timeout
$ ls $D                  # nothing written
out.log                  # contains the Kilo Code TUI banner

Working (identical, minus the bogus subcommand):

$ kilo "Create a file kilo_probe.txt containing exactly: works" --auto --workspace $D
exit=0
$ ls $D
kilo_probe.txt           # "✓ Task Completed / Created kilo_probe.txt with the content 'works'"

--workspace is honoured, so unlike #1007 there is no cwd problem here — only the invented subcommand.

Changes

The invocation — run removed; the prompt is the leading positional.

require_file_changes=True — the TUI path could exit 0 having written nothing, and gates would then run on an unchanged tree with the task markable DONE. Same guard claude-code got in #739/#819 and opencode in #913. KilocodeAdapter was the last shipped coding-agent adapter without it.

The unit test was pinning the bug. It asserted cmd[1] == "run" — i.e. that the adapter agrees with itself. It now asserts the prompt is the leading positional and that run is absent, so restoring the bug fails the suite.

A binary-gated smoke tier (test_kilocode_smoke_1012.py) runs the adapter's own build_command output against the installed kilo:

• kilo --help lists no run command — asserted against the CLI's own help, so it fails if kilocode ever adds one and the adapter needs revisiting
• the old invocation hangs and writes nothing (pins the bug, so nobody restores it believing it worked)
• the adapter's command writes a real file — not "exit 0", which the TUI path could also produce
• a run that writes nothing is not reported completed

Demo — real binary

tests/core/adapters/test_kilocode_smoke_1012.py .....            [100%]
5 passed in 53.95s

  17.2s  test_the_adapter_command_actually_writes_a_file          -> smoke.txt written
   9.8s  test_a_run_that_writes_nothing_is_not_reported_completed -> guard fired
  20.0s  test_the_old_invocation_hangs_and_writes_nothing         -> timeout, no file

The file on disk is the outcome evidence: the adapter drove real kilocode to completion and the delegated agent wrote real code.

Review

codex review --base main (cross-family, pre-PR) raised one [P2]: gating the smoke tests on shutil.which alone meant a plain uv run pytest on any machine with the CLI installed would start making real model calls — real credentials, real money, network-dependent flakiness.

Confirmed and fixed in 2d8937f: both smoke files now also require CODEFRAME_ENGINE_SMOKE=1. I applied it to the pre-existing opencode smoke file too, since it had the same defect. Verified both directions:

default:                     202 passed,  9 skipped in  2.3s   (was 53s of real model calls)
CODEFRAME_ENGINE_SMOKE=1:      5 passed             in 54.0s   (real kilo, real files)

Tests

tests/core/adapters/ — 202 passed, 9 skipped (default); +5 real-binary tests under the opt-in flag. ruff check clean.

Known limitations

• The workflow that sets CODEFRAME_ENGINE_SMOKE=1 on a schedule with the binaries installed is [P0.21] Run every shipped engine adapter against its real CLI in a binary-gated smoke/contract tier #915 (P0.21), which this unblocks — its AC1 requires driving a task to a terminal state per engine, which kilocode could not do before this.
• The prompt is still a single positional argument, so kilocode inherits the argv size ceiling that [P0.19] Invoke opencode run and require file changes for the OpenCode engine #913 addressed for opencode (macOS caps at 256 KB; Linux at 128 KB per argument). The existing docstring notes it. kilocode has no documented stdin path to fall back to, so unlike opencode there is no fix available here — flagging rather than silently leaving it undocumented.

[github-actions]

Claude finished @frankbria's task in 3m 32s —— View job

---

GLM precision review — no defects found

Scoped to concrete defects only (logic errors, null/unhandled error paths, security, data loss, contract breaks, resource leaks). Style, architecture, naming, and test coverage are handled by a separate general-purpose review and intentionally not commented on here.

What I verified against the checked-out code

• codeframe/core/adapters/kilocode.py — the run removal and the new require_file_changes=True. Traced the full lifecycle in subprocess_adapter.py:96-267:
  • Subprocess timeout → failed at subprocess_adapter.py:181-185, before the require_file_changes guard — a hang can never be mis-read as completed.
  • kilo's own exit-124 (_map_result → failed, kilocode.py:135) and any non-zero exit also bypass the guard, which requires status == "completed" (subprocess_adapter.py:227-231).
  • The guard fires only on exit-0 + empty modified_files + no advancing HEAD + a resolvable git repo — identical to the established claude-code ([P1.12] claude-code engine denies file edits by default (--print with no permission config) #739/[P2.23] claude-code engine: harden require_file_changes + bypassPermissions follow-ups (from #739 review) #819) and opencode ([P0.19] Invoke opencode run and require file changes for the OpenCode engine #913) pattern. No new failure mode introduced.
• detect_modified_files (git_utils.py) returns repo-relative paths; kilo writes into --workspace, which equals both the subprocess cwd and the path passed to detection — no path-mismatch defect (the [P0.27] OpenCode adapter writes outside the workspace — opencode ignores the subprocess cwd #1007 class).
• The autouse _no_git fixture now returns ["main.py"] and patches _git_head, which keeps the existing exit-0 / 124-timeout / nonzero / event-callback tests green — the guard never trips on the "did work" path (not modified_files is False).
• test_opencode_smoke_913.py is a pure additive skipif marker; no logic altered.

No findings to report.

[github-actions]

✅ GLM review: no defects found.

Scoped to concrete defects (logic errors, unhandled error paths, security, data loss, contract breaks, resource leaks). Traced the kilocode invocation fix and the require_file_changes=True guard through SubprocessAdapter.run() and detect_modified_files: timeout/exit-124/non-zero paths all resolve to failed before the guard, and the guard matches the established claude-code (#739/#819) and opencode (#913) pattern. No inline findings.