Agent status hooks for Kimi Code CLI — installer target or cookbook recipe?

[x9x9x9x9x9x91]

Problem: the agent-status hooks installer (Help ▸ Install Agent Status Hooks…) covers Claude Code, Codex, Pi, and OpenCode — but not Kimi Code CLI (kimi), Moonshot's coding agent. Kimi sessions running inside agterm show no sidebar glyphs, so among mixed agent sessions the kimi rows are the ones you can't triage at a glance.

Why it looks cheap to add: Kimi Code has a Claude-Code-style hook system (docs) — [[hooks]] entries in ~/.kimi-code/config.toml, JSON payload on stdin, and the event names line up almost one-to-one with what the Claude hooks already use:

glyph	Claude Code hook	Kimi Code hook
active	UserPromptSubmit, PostToolUse	UserPromptSubmit, PostToolUse
blocked	Notification (matcher permission_prompt)	PermissionRequest
completed	Stop	Stop

Verified locally (kimi-code 0.31.0, agterm 0.19.1): I pointed the four events above at the stock agterm-agent-status.sh — unmodified — and the glyphs behave correctly: blink during a live turn, green check on Stop, --auto-reset clears on visit. Config used:

[[hooks]]
event = "UserPromptSubmit"
command = "$HOME/.config/agterm/agent-status/agterm-agent-status.sh active --blink"

[[hooks]]
event = "PostToolUse"
command = "$HOME/.config/agterm/agent-status/agterm-agent-status.sh active --blink"

[[hooks]]
event = "PermissionRequest"
command = "$HOME/.config/agterm/agent-status/agterm-agent-status.sh blocked"

[[hooks]]
event = "Stop"
command = "$HOME/.config/agterm/agent-status/agterm-agent-status.sh completed --auto-reset"

Two kimi-specific facts worth knowing before deciding anything:

• Kimi treats a hook's exit code 2 as a block and injects its stderr into model context, and a Stop hook's stdout can be fed back as context — so the status script's existing always-exit-0 / suppress-output discipline is exactly right for kimi too, and worth keeping strict.
• PermissionRequest is observation-only and fires right before the approval prompt — no Auto-Review-style false-flag problem, so kimi should not need the pane-watcher workaround the Codex hook carries. Caveat: my test runs used kimi's auto permission mode, so I've verified active/completed live but not yet seen PermissionRequest fire — I'd exercise that path properly before any PR.

The question: would you want kimi support as (a) a new target in the installer alongside the existing four, (b) a cookbook recipe (config snippet + README), or (c) not in scope? Happy to build and PR whichever shape fits — asking first per CONTRIBUTING before writing anything.

[umputun]

cookbook recipe, (b).

the installer can't cover every agent out of the box, so the bar is how many agterm users actually run the thing, weighed against what the target costs to carry. Each of the current four needs app-side code: a bundled wrapper or extension file, an ownership marker, a merge that parses and rewrites someone's existing ~/.claude/settings.json or ~/.codex/config.toml, and tests for all of it. That is permanent surface in the app and one more thing that breaks when the agent changes its config format.

kimi is niche in this user base today, and it also needs none of that machinery. The stock agterm-agent-status.sh works unmodified, so the whole delta is four [[hooks]] entries pasted into ~/.kimi-code/config.toml. That is a config snippet plus an explanation, which is what the cookbook is for. A recipe with no script is fine, overlay-and-split is README-only for the same reason.

for the PR:

• work the minimum agterm version out from what you use (the script path, --blink, --auto-reset), not the version you happen to run, per cookbook/CONTRIBUTING.md.
• exercise PermissionRequest for real before sending. If it does false-flag the way codex's raw Notification does, don't port the pane-watcher into the recipe, put the behavior in Limits and say plainly what the reader will see.
• the exit-code-2-blocks and Stop-stdout-as-context facts belong in How it works, that is the gotcha the section exists for.

on the longer term: recipes are not a synchronized surface, they pin a version and get fixed when someone reports a break. If kimi picks up enough agterm users for the recipe to be reported broken often, that is the signal to revisit the installer.