kimchi-acp-provider — the Kimchi harness over ACP

Hermes Agent model-provider plugin: Hermes spawns the Kimchi coding harness (kimchi --mode acp) and the harness itself serves each turn over stdio (Agent Client Protocol). The harness's own tools (shell, file edits, web search) execute inside the harness; completed tool calls are surfaced in the reply as markdown bullets (- ⚙ **web_search** ✓ — excerpt).

This is Layer 2 — the primary use case — of the kimchi-hermes monorepo. The API-key alternative kimchi-provider keeps Hermes' tool pipeline in charge instead.

Install

hermes plugins install getkimchi/kimchi-hermes/model-providers/kimchi-acp
# or, once listed in the Hermes plugin catalog:
hermes plugins install kimchi-acp-provider

Prerequisites

The Kimchi CLI on PATH and logged in (kimchi login). The subprocess owns its own auth — no API key is shared with Hermes.

Use

hermes model    # pick "Kimchi (Harness via ACP)"
hermes          # tool-using turns show inline harness tool bullets

The model picker lists the harness's live advertised models (provider-prefixed ids such as kimchi-dev/..., plus its auto router mode). The kimchi-acp row means "harness session default" (no explicit model selection).

Environment variables

Variable	Purpose
`KIMCHI_ACP_COMMAND`	Override the spawned binary (default `kimchi`). In GUI apps (Hermes Desktop), point this at the absolute binary path — GUI apps do not inherit your shell PATH.
`KIMCHI_ACP_ARGS`	Override the spawn args. Trap: an empty value falls back to the default args — YOLO (no approval prompts) is opt-in: set `KIMCHI_ACP_ARGS="--mode acp --yolo"`.

Behaviour & disclosures

Subprocess: every turn spawns kimchi --mode acp and speaks JSON-RPC over stdio; the process is terminated when the turn ends. By default the harness keeps its own tool-permission prompts. Because Hermes' ACP shim has no human approval channel yet, those requests are cancelled fail-safe (see the monorepo README's roadmap for the full picture and the upstream feature request it implies) — so the practical default is: tools that require approval don't run, nothing executes silently. YOLO — Kimchi's no-restrictions permission mode, where harness tools (shell commands, file writes, web requests) execute without approval prompts — is opt-in: KIMCHI_ACP_ARGS="--mode acp --yolo". Enable it only where you accept unsupervised in-harness execution (e.g. your own machine, not shared gateway/cron contexts).
Reads outside the plugin's own data: to report setup status, the plugin checks whether the Kimchi CLI is logged in by reading the Kimchi CLI's own config (~/.config/kimchi/config.json, or KIMCHI_CONFIG_PATH overridable) — the config is parsed only to check that a stored key is present; the key itself is never stored by Hermes nor sent anywhere.
Auth: env_vars=() — the harness subprocess authenticates itself with its own credential store; Hermes never handles a Kimchi key on this path.
Reply rendering: completed/failed tool calls are rendered as one markdown bullet each in the visible reply (registration and in-progress churn suppressed), so harness tool activity is visible in Hermes' UI and reaches later turns' context.
Registers only a provider profile (register_provider); no tools, no hooks, no middleware.

Known limitations

No incremental streaming — Hermes' ACP shim blocks until the turn completes, then chunks the result; each turn also pays a fresh-process cold start.
Images are dropped on the ACP path (vision unsupported here; the API-key kimchi-provider layer is unaffected).
In-session yes/no confirms from the harness degrade to "no" (fail-safe).

Details, evidence and the decision log: monorepo README and SPEC.md.