0.34.0 regression (macOS): interactive TUI never executes [[hooks]] (SessionStart/UserPromptSubmit/SessionHeartbeat); kimi -p works

Version: kimi-code 0.34.0 (macOS 15, arm64, ~/.kimi-code/bin/kimi, auto-updated from 0.33.0 on 2026-08-10)
Config: ~/.kimi-code/config.toml — two [[hooks]] entries (SessionStart, SessionEnd). kimi doctor reports the file valid.

Summary

After auto-updating from 0.33.0 to 0.34.0, the interactive TUI never executes any configured [[hooks]] — verified for SessionStart, UserPromptSubmit, and SessionHeartbeat. The same config works correctly in headless mode (kimi -p), where SessionStart fires and the hook command runs. On 0.33.0 the same hooks fired reliably in interactive sessions (daily use for weeks).

Config

[[hooks]]
event = "SessionStart"
command = "/Applications/QuotaWidget.app/Contents/MacOS/QuotaWidget --session-start"
timeout = 5

[[hooks]]
event = "SessionEnd"
command = "/Applications/QuotaWidget.app/Contents/MacOS/QuotaWidget --session-end"
timeout = 5

(The hook launches a floating quota-widget; this is how the regression was noticed — the widget stopped auto-starting.)

Steps to reproduce

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

   [[hooks]]
   event = "SessionStart"
   command = "/bin/bash -c 'echo $(date -u +%FT%TZ) SessionStart >> /tmp/hook-probe.log'"
   
   [[hooks]]
   event = "UserPromptSubmit"
   command = "/bin/bash -c 'echo $(date -u +%FT%TZ) UserPromptSubmit >> /tmp/hook-probe.log'"
   
   [[hooks]]
   event = "SessionHeartbeat"
   command = "/bin/bash -c 'echo $(date -u +%FT%TZ) SessionHeartbeat >> /tmp/hook-probe.log'"
   

2. Start an interactive TUI session (also reproducible under a pty: (printf 'hi\n'; sleep 80) | script -q /tmp/tui.log kimi), send a message, wait 80 s.

3. Observe: /tmp/hook-probe.log is never created — none of the three events fire.

4. Control: kimi -p "hi" with the same config → /tmp/hook-probe.log gets a SessionStart line and the hook command executes successfully.

Observed vs expected

• Expected (per docs and 0.33.0 behavior): interactive sessions fire hooks identically to headless ones.
• Actual: interactive TUI silently runs zero hooks; no warning, no log line, kimi doctor says everything is valid.

Additional clues

• Running the same binary with KIMI_CODE_LEGACY_FLAG=1 surfaced the only feedback anywhere: the TUI rendered a warning "Ignored invalid config in ~/.kimi-code/config.toml: hooks. Run kimi doctor for details." — while kimi doctor reports all config files valid. (Caveat: at that moment the config also contained the three probe hooks above; the warning may concern one of the newer event names. Either way, the legacy engine says the hooks section is invalid and doctor disagrees.)
• The default (v2) engine shows no such warning — it just never runs the hooks, which matches the silent-failure pattern described in #2766 (loadSafe() / trigger() swallow everything).
• Possibly related to #2070 (interactive sessions ignoring [[hooks]]), but note that on macOS this is a regression between 0.33.0 and 0.34.0: 0.33.0 interactive sessions fired these hooks correctly.

Impact

Any tooling that keys off SessionStart/SessionEnd (launch-on-start widgets, session trackers) or UserPromptSubmit (context injection) silently stops working in the primary interactive use case after the 0.34.0 auto-update, with no user-facing signal.

Happy to provide session ids / wire logs from the reproduction runs if useful.

Start by comparing hook handling in the interactive TUI with headless kimi -p, using the reported loadSafe() and trigger() paths as entry points. Reproduce with the probe hooks and inspect the kimi doctor and KIMI_CODE_LEGACY_FLAG=1 behavior. Done means valid hooks execute for interactive SessionStart, UserPromptSubmit, and SessionHeartbeat events without silent failure.