Approval prompt never renders in web/desktop/VS Code clients when a PreToolUse or SessionHeartbeat hook is configured — pending call is then silently approved

Environment

• OS: macOS (arm64)
• Kimi Code CLI: 0.43.1, reproduced again after upgrading to 2.0.0
• Clients affected: kimi web official web UI, Kimi Code desktop app 1.0.1, VS Code extension 0.7.5
• Terminal TUI: not affected (approval prompts render and wait for input normally)

Summary

When a hook is configured on PreToolUse (or SessionHeartbeat), approval requests never render in server-driven clients (web UI, desktop app, VS Code extension). The desktop app shows an "Internal error occurred." toast instead. Worse: the pending approval is later resolved as approved with zero user interaction, and the tool call — including destructive commands such as rm — executes unattended. In manual (Always Ask) permission mode this silently disables the human approval gate.

Steps to reproduce

1. Add to ~/.kimi-code/config.toml:

   [[hooks]]
   event = "PreToolUse"
   command = "/bin/true"
   

   The hook binary itself is irrelevant; any hook that exits 0 quickly reproduces the issue.

2. Open a session in the web UI (kimi web), permission mode: Always Ask (manual).

3. Have the agent run a command that requires approval, e.g. create a temp file with touch /tmp/probe.txt, then delete it with rm /tmp/probe.txt.

4. Observe: no approval card appears; the command executes regardless.

Expected behavior

• Approval prompts render in every client regardless of hook configuration.
• If approval delivery or rendering fails for any reason, the decision must fail closed (deny the call or surface an error). It must never resolve as approved on its own.

Actual behavior

• No approval UI in web/desktop/VS Code clients; desktop app shows an "Internal error occurred." toast.

• The session wire log shows the approval resolved without any client/user action in between:

  {"type":"interaction.request","kind":"approval","toolName":"Bash","action":"Running: rm /tmp/probe.txt"}
  {"type":"interaction.resolved","response":{"decision":"approved"}}
  {"type":"permission.record_approval_result","toolName":"Bash","action":"Running: rm /tmp/probe.txt","result":{"decision":"approved"}}
  

• The tool executes.

Bisect

Same session, one variable at a time; does the approval card render?

Pattern: hooks that fire before or while an approval is pending break the approval UI; events firing at or after the approval are harmless. UserPromptSubmit was not tested in isolation but falls into the "fires before the approval" group. Results identical on CLI 0.43.1 and 2.0.0.

Impact

Security-relevant. In manual mode the user expects every sensitive operation to wait for an explicit decision. With such hooks configured — a documented, supported feature — that guarantee silently disappears: approvals resolve themselves and commands run unattended. Not remotely exploitable (requires a local hook configuration), but the failure mode must be fail-closed, not fail-open.

Notes

• The hook in our real setup exits 0, writes nothing to stdout, and completes in under a second; it complies with the documented hook contract.
• Desktop app log, VS Code extension bridge log (respondApproval entries with no corresponding user action), and session wire logs available on request.

Reproduce with the documented PreToolUse or SessionHeartbeat hook in ~/.kimi-code/config.toml, then compare the web UI, desktop app, VS Code extension, and unaffected terminal TUI while capturing the session wire log. Trace interaction.request through interaction.resolved and permission.record_approval_result; done means approval renders in affected clients and any delivery or rendering failure denies or surfaces an error rather than approving.