Feature Request: let PermissionRequest hooks decide approvals (allow/deny) behind an experimental flag

What feature would you like to see?

Summary

I want external tools to be able to participate in Kimi Code's approval flow: when the agent is about to prompt the user to approve a tool call (for example, exiting Plan mode), a configured hook should be able to answer that approval itself — approve it, or reject it with feedback — instead of the built-in prompt.

Motivation and current problem

Several coding agents expose a hook event that fires when the agent is about to show an approval prompt, and the hook's output can decide the prompt's outcome. Tools in the ecosystem build on this to provide richer approval UX. A concrete example: plan-review tools such as Plannotator integrate with Claude Code, Copilot CLI, Gemini CLI, and others by registering a hook on ExitPlanMode; the hook serves a browser page where the user annotates the plan and chats with an AI about it, then returns a structured decision — on approve the plan executes, on deny the annotated feedback goes back to the model so it can revise the plan.

This kind of integration is impossible on Kimi Code today:

• PermissionRequest is observation-only: it fires before the approval prompt, but the hook's output is ignored (fire-and-forget), so a hook can neither approve nor reject with feedback.
• PreToolUse can only allow or block tool execution up front. A block surfaces as a rejection error, not as review feedback, and for ExitPlanMode the plan text is not even in tool_input (it is carried in the display payload), so the hook never sees the plan.
• Hook timeout is capped at 600 seconds, which is too small for interactive review flows where a user may think for minutes.

As a result, no external review/approval tool can hook into Kimi Code's approval UX.

Proposed solution

A generic, opt-in capability (no tool-specific behavior in core), gated by a new experimental flag hook_permission_decisions (env KIMI_CODE_EXPERIMENTAL_HOOK_PERMISSION_DECISIONS, or [experimental] in config.toml; default off, behavior unchanged when off):

1. When the flag is on and an approval prompt would be shown, matching PermissionRequest hooks run first and are awaited, receiving the full approval context on stdin (tool_name, tool_input, action, display — for plan reviews including the plan text — and the request ids).
2. Hooks answer with the existing hook output vocabulary: hookSpecificOutput.permissionDecision: "allow" | "deny" plus permissionDecisionReason. allow approves the tool call; deny rejects it and the reason is fed back to the model (for ExitPlanMode this lands in the existing revise-the-plan loop).
3. Fail-open semantics: no output, unrecognized values, timeout, or crash all fall back to the normal approval prompt. Across multiple matching hooks, a single deny wins. Headless sessions (no approval broker) are unaffected.
4. Raise the hook timeout cap from 600 to 86400 seconds so interactive review flows are expressible (default stays 30s).

The design is deliberately tool-agnostic: anything that can answer an approval — a browser review UI, a remote approval bridge, an internal policy service, a chat-ops bot — can build on the same mechanism, and none of it requires core changes beyond this one capability.

Alternatives considered

• A new dedicated hook event: same semantics as PermissionRequest; would duplicate the event for no gain.
• Extending PreToolUse: wrong layer — it runs before the approval decision exists and cannot express "approved".
• Intercepting in the TUI: not installable as a plugin and would not cover kimi web / kap-server sessions; doing it in the engine covers every surface.

Contribution

I have a working implementation ready, and I'm happy to open a PR if the approach sounds good.

Additional information

No response

Start by tracing the PermissionRequest and PreToolUse hook paths, the ExitPlanMode approval flow, and experimental settings in config.toml or KIMI_CODE_EXPERIMENTAL_HOOK_PERMISSION_DECISIONS. Done means the opt-in hooks can return the existing allow/deny decisions with feedback, failures fall back to the normal prompt, and the timeout cap supports interactive reviews.