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

[seasonmsg]

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.

[seasonmsg]

Follow-up: still reproduced on 0.29.0 (interactive), same machine / same config

Upgraded to 0.29.0 via auto-update and re-ran the probes in a fresh interactive session (2026-07-22 ~15:42Z). Not fixed:

• kimi --version → 0.29.0; ~/.kimi-code/config.toml unchanged and valid (45 [[permission.rules]] + 2 [[hooks]] still present).
• PreToolUse heartbeat: file timestamp unchanged (last beat 2026-07-22 14:42Z, from a manual hook run) after 20+ tool calls in the interactive session.
• UserPromptSubmit hook: no marker / no prompt injection on the session's first user message.
• Deny-rule probe: an Edit on the protected path succeeded in the interactive session (immediately reverted; git status verified clean). The identical rule denies the same Edit in headless (-p) sessions.

Conclusion: as of 0.29.0, hooks and permission rules are still enforced only in headless sessions; interactive sessions remain fail-open. Debug ZIP / wire.jsonl from this 0.29.0 session available on request.

[he-yufeng]

Tried to pin this down from source on current main (188c0fc), and the default engine does not seem to have a spot where interactive and headless diverge on this:

• Both the TUI and kimi -p (default v1 engine) build sessions through createSessionWithOverrides in packages/agent-core/src/rpc/core-impl.ts, which spreads config.hooks and config.permission?.rules into every session (lines 372-373; the resume path at 523 does the same). UserPromptSubmit is triggered from agent/turn/index.ts, PreToolUse from agent/permission/policies/pre-tool-call-hook.ts.
• The v1 config schema accepts exactly the [[hooks]] and [[permission.rules]] shapes from your file, and the rule path matcher already normalizes Windows separators (tools/support/path-glob-match.ts adds slash-form variants and canonicalizes against cwd before globbing).

Two questions that would narrow it down a lot:

1. Is KIMI_CODE_EXPERIMENTAL_FLAG set in the shell where your headless probes enforced the config? That flag routes kimi -p to the agent-core-v2 engine, which loads the same sections through a different config service. If the enforcing headless runs were v2 and the TUI is v1, the split is between engines rather than between interactive and headless.
2. For the deny rule: does a bare decision="deny", pattern="Edit" (tool name only, no path glob) block in an interactive session? If that also fails, the rule list never reaches the interactive session at all. If it blocks, the gap is in path matching, and the exact file_path the Edit tool receives on your Windows setup is the next thing to compare against the pattern.

[seasonmsg]

Follow-up #2: hooks partially initialize mid-session; enforcement still broken (0.29.0)

New evidence from the same interactive session that reproduced the bug on 0.29.0:

• At session start: hooks dead — heartbeat file untouched by 20+ tool calls, no UserPromptSubmit injection, deny-rule Edit probe succeeded (all as previously reported).
• ~1.5h into the session, after a permission-mode change (to "auto" and later back), hooks started firing: the PreToolUse heartbeat now updates on every tool call, and UserPromptSubmit injection appeared on subsequent user messages. The mode toggle is the suspected trigger (correlation, not proven causation; a controlled experiment in a fresh window is planned).
• Despite hooks now executing, enforcement remains dead: the same deny-rule Edit probe succeeded again, and a Bash command embedding a fake secret pattern — which our PreToolUse hook is designed to block — executed unblocked.

So on 0.29.0: hook scripts can execute (apparently after some lazy initialization), but neither permission.rules decisions nor hook block decisions take effect in interactive sessions. Headless (-p) sessions enforce both. This points at the decision/enforcement path of interactive sessions rather than at hook loading itself.

[he-yufeng]

Follow-up #2 narrows it a lot. Two things from the v1 policy chain that sharpen the split:

1. Enforcement in v1 is mode-independent by construction. The decision chain runs PreToolCallHookPermissionPolicy first (packages/agent-core/src/agent/permission/policies/index.ts:31, hook block lands as deny), then UserConfiguredDenyPermissionPolicy (line 39, reading agent.permission.data().rules), and only later AutoModeApprovePermissionPolicy (line 41) and GitCwdWriteApprovePermissionPolicy (line 66, which silently approves Write/Edit inside the cwd of a git work tree when nothing above matched). So an Edit probe that executes with no prompt is consistent with one reading: the session's permission.rules list was empty at that moment, and the git-cwd write-approve policy took it. Not "rules failed to match", but "rules never made it into the session".

2. In v1 there is no hooks reload on permission-mode change. agent.hooks is fixed at session construction from the session's hooks option (session/index.ts -> agent/index.ts:190), and nothing re-populates it when you flip modes. If PreToolUse firing only started after your toggle, whatever populated the hook engine mid-session is not in the v1 wiring. That makes me suspect the interactive session on your build is not the in-process v1 path I traced (TUI -> node-sdk harness -> core-impl), but something with lazily-initialized services.

Two probes that would separate the remaining cases cleanly:

• Does the Edit probe show an approval prompt at all, or does it execute with zero interaction? Zero interaction + executed = the git-cwd auto-approve fired (rules absent), which you could confirm by trying the same probe on a path outside the git work tree (that one should fall to the fallback ask).
• What exact output does your blocking hook emit? If it blocks via exit code 2 but the engine reads a JSON decision field (or vice versa), the hook fires and its block never lands. That would explain "heartbeat updates, no enforcement" for the hook half, independently of the rules half.

[seasonmsg]

New evidence from a fresh interactive session on the same build (0.29.0), run as a controlled experiment against the lazy-initialization hypothesis:

• Hooks were alive from the very first message — UserPromptSubmit injection present on message docs: fix typo in zh readme #1, PreToolUse heartbeat fresh after the first tool calls. No permission-mode toggle was needed. The lazy-init hypothesis (hooks load only after a mode switch) is therefore falsified; the earlier correlation was coincidental or the trigger is something else (e.g. a persisted mode change, or an async init race).
• Enforcement is split into three layers, not two: (1) hook execution = alive; (2) hook block decisions = alive — our PreToolUse hook blocked both a Bash command and a Read call referencing a sensitive path (the kimi-code config TOML under the user home) with exit 2, and the blocks took effect; (3) permission.rules deny decisions = still dead — the same deny-rule Edit probe on a protected file succeeded again (reverted and verified clean).
• In the previous session the hook block path was observed dead (a fake-secret curl ran unblocked) while in this session it is alive — both states on the same version, trigger unknown. We also checked whether default_permission_mode = "auto" explains the difference: all historical config backups (including one predating our gate setup) already had auto, and both the previously-dead session and the now-alive session ran with the same default — so the permission-mode value is not the trigger. An initialization timing race is our leading candidate.

So on 0.29.0 interactive sessions: hook scripts execute and their exit-2 blocks can take effect, but permission.rules decisions never do. This narrows the root cause to the permission-rule evaluation path alone; hook loading/enforcement is flaky but functional.