0.34.0: agent-core-v2 startup file watcher dies with EMFILE on macOS (any directory, ample fd limits; legacy engine unaffected)

Bug description

On macOS, kimi-code 0.34.0 crashes at startup with EMFILE: too many open files, watch from the agent-core-v2 file watcher — in any directory, including a completely empty one — before any prompt can be entered. Both the interactive TUI and kimi -p are affected. The legacy engine (KIMI_CODE_LEGACY_FLAG=1) works perfectly, so this is a v2-engine regression.

This looks distinct from #2542 / #2612 (skill-root watch fd footprint, fixed in 0.33.0): that issue needed a large file tree to gradually exhaust fds, while this one fails instantly at startup even in an empty directory with verified-ample limits (details below). Possibly a second watch path that didn't get the #2612 treatment, or a regression in the fix.

Environment

• kimi-code 0.34.0 (auto-updated 2026-08-07; binary ~/.kimi-code/bin/kimi, 176 MB)
• macOS, Apple Silicon (arm64)
• Embedded Node.js v24.15.0 (from the crash banner)
• kimi doctor: both config files valid

Reproduction (100%)

mkdir -p /tmp/kimi-empty && cd /tmp/kimi-empty
kimi -p "hi"        # or just `kimi` for the TUI

Within ~1 second:

[unexpected] Error: EMFILE: too many open files, watch
    at FSWatcher._handle.onchange (node:internal/fs/watchers:267:21) {
  errno: -24,
  syscall: 'watch',
  code: 'EMFILE',
  filename: null
}

then the process dies on the unhandled 'error' event (node:events:487). Reproduced in an empty scratch dir, in a small project (~1.5k dirs, 26k files), and in a large monorepo — identical every time.

What we ruled out

• Per-process fd limit: soft limit 65,536 (launchctl) / 1,048,575 (shell); the dying process never gets near it.
• System-wide fd pressure: kern.num_files ≈ 54k of kern.maxfiles 491k at failure time.
• Watcher capacity in a plain Node process (same machine, same minute): 6,000 concurrent fs.watch file watchers OK; 2,000 concurrent directory watchers OK.
• Project content: empty directory reproduces it, so nothing in any workspace tree (size, symlinks, .gitignore coverage) is the trigger.
• Config: kimi doctor reports both config.toml and tui.toml valid.

Control experiment

KIMI_CODE_LEGACY_FLAG=1 kimi -p "hi"   # works — full prompt/response cycle, zero EMFILE

So the crashing watcher belongs to the agent-core-v2 engine path (default since 0.33.0). Note the binary contains KIMI_CODE_FS_WATCH_DEBOUNCE_MS / KIMI_CODE_FS_WATCH_MAX_CHANGES_PER_WINDOW tunables, but the failure is at watch registration, not in the change-delivery path.

Expected behavior

kimi starts without EMFILE on macOS regardless of directory contents, as it did before the 0.34.0 auto-update (and as it still does with the legacy flag).

Happy to provide

Full crash logs, lsof snapshots, or a test of any candidate fix build. If there's a debug/env flag to make the v2 watcher log the paths it registers at startup, I'll run it and attach the output.

Reproduce the failure with kimi -p "hi" in an empty directory, then compare the default agent-core-v2 startup path with KIMI_CODE_LEGACY_FLAG=1. Trace the v2 file-watcher registration and its startup error handling; done means kimi starts on macOS without EMFILE regardless of directory contents.