Interactive sessions ignore [[hooks]] and [[permission.rules]] from config.toml; headless (-p) sessions enforce them (0.28.1, Windows)

Version: kimi-code 0.28.1 (native Windows install, ~/.kimi-code/bin/kimi)
OS: Windows 11 (Git Bash environment)
Config: ~/.kimi-code/config.toml — 45 [[permission.rules]] + 2 [[hooks]] (PreToolUse, UserPromptSubmit). kimi doctor config reports the file valid.

Summary

In interactive sessions, neither [[hooks]] nor [[permission.rules]] from config.toml are enforced — PreToolUse/UserPromptSubmit hooks never run, and deny rules never block. In headless sessions (kimi -p), the exact same config file works: hooks fire and deny rules block. Two independent interactive sessions reproduced this; multiple headless sessions confirmed enforcement.

Steps to reproduce

1. Register in ~/.kimi-code/config.toml:
   • a [[hooks]] PreToolUse hook (matcher Bash|Read|Write|Edit|...) that appends a heartbeat file on every invocation;
   • a [[hooks]] UserPromptSubmit hook that writes a marker file and prints a line;
   • a [[permission.rules]] entry decision="deny", pattern="Edit(**/protected-dir/**)".
2. Open an interactive session in the project directory.
3. Make tool calls (Bash/Read/Edit), including an Edit on a file under protected-dir/.
4. Observe: heartbeat file never updates; no marker file appears; the Edit on the protected path succeeds.
5. Repeat in kimi -p headless session: heartbeat updates, marker appears, same Edit is denied with the rule's reason string.

Evidence (available on request; session ids below)

• Interactive session A (session_68457ee1-..., 2026-07-22 14:37Z): 10+ tool calls, heartbeat untouched; Edit on protected file succeeded (immediately reverted); no UserPromptSubmit marker.
• Interactive session B (session_713e5185-..., 14:29–14:35Z): Write of a project file at 14:35Z did not update the hook heartbeat (last beat 14:31:47Z from a headless session).
• Headless session (session_31ac3ae7-..., 14:31Z): UserPromptSubmit hook fired (marker written); Edit on the same protected file denied by permission rule ("denied by permission rule. Reason: ..." in wire log).
• The hook script itself is healthy: run manually with a JSON payload it exits 0 and writes the heartbeat.
• No hook/permission errors in ~/.kimi-code/logs/kimi-code.log.

Expected vs actual

Expected (per docs: hooks and permission rules "take effect on every startup" / "loaded when a session starts"): identical enforcement in interactive and headless sessions.
Actual: enforcement only in headless (-p) sessions; interactive sessions silently run with no hooks and no permission rules.

Impact

Configs that rely on hooks/permission rules as a safety barrier (secret-leak prevention, protected paths) are silently inactive in the primary interactive use case — a fail-open condition with no user-facing warning.

Notes

• Auto-update offered 0.29.0 (rollout-held); if this is already fixed in 0.29.0, a changelog pointer would be appreciated.
• Debug ZIP / wire.jsonl from all referenced sessions can be provided via /feedback follow-up.

Start by reproducing the behavior with the config.toml hooks and permission.rules in both an interactive session and a kimi -p headless session, comparing the session logs and wire evidence described in the report. Trace the separate interactive and headless startup paths; done means both modes load the same configuration, run the hooks, and enforce the protected-path deny rule with tests or equivalent reproduction evidence.