MoonshotAI / MoonshotAI/kimi-code

Startup crash: EMFILE: too many open files, watch — kimi auto-registers and watches every ancestor directory up to /

Open
#2,929 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

Title

Startup crash: EMFILE: too many open files, watch — kimi auto-registers and watches every ancestor directory up to /

Environment

  • kimi-code version: 0.36.1 (latest, via kimi --version)
  • OS: macOS (Darwin 25.5.0), arm64
  • Node.js: v24.15.0
  • Shell: zsh
  • ulimit -Sn: tested from 1048576 down to default; also tested explicit ulimit -n 200000 before launch — same crash
  • launchctl limit maxfiles: soft 256 / hard unlimited (default macOS)
  • kern.maxfilesperproc: 245760 (sysctl)

Summary

On every launch, kimi-code registers a "workspace" entry in ~/.kimi-code/workspaces.json for the current working directory and for every ancestor directory up to and including filesystem root / (e.g. ~/Development/my-project~/Development~/). It then appears to eagerly file-watch all registered workspace roots (not just the active one), which for the ~ and / entries means recursively watching the entire home directory and the entire filesystem. This exhausts available file watchers almost immediately and crashes with an uncaught EMFILE error.

Steps to reproduce

  1. cd into any project directory nested a couple of levels under $HOME (e.g. ~/Development/some-project).
  2. Run kimi -p "reply with just OK" (non-interactive prompt mode makes the crash deterministic/uncaught; interactive TUI mode logs two [unexpected] caught EMFILE errors first and may crash shortly after depending on what else is watched).
  3. Observe the process crash with an unhandled FSWatcher error event.

Actual behavior

[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
}
[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
}
node:events:487
      throw er; // Unhandled 'error' event
      ^

Error: EMFILE: too many open files, watch
    at FSWatcher._handle.onchange (node:internal/fs/watchers:267:21)
Emitted 'error' event on FSWatcher instance at:
    at FSWatcher._handle.onchange (node:internal/fs/watchers:273:12) {
  errno: -24,
  syscall: 'watch',
  code: 'EMFILE',
  filename: null
}

Node.js v24.15.0

The first two EMFILE errors are caught (logged as [unexpected]) but a third one is not, and takes down the whole process.

Evidence it's the ancestor-walk, not a one-off fluke

Inspecting ~/.kimi-code/workspaces.json before and after a single launch from ~/Development/dfx-video-ident:

  • Before: only per-project entries present (I had manually pruned the file to test).
  • After one launch: kimi re-added, within the same second:
    • {"root":"/Users/johndefalco","name":"johndefalco", ...} (entire home directory)
    • {"root":"/Users/johndefalco/Development","name":"Development", ...} (parent dir containing every other project, each with its own node_modules)
    • {"root":"/","name":"", ...} (filesystem root — workspace id wd_workspace_e3b0c44298fc, which is the first 12 hex chars of sha256(""), suggesting an empty-string path is being resolved to / somewhere in the ancestor-walk/normalization logic)

This happens unconditionally on every launch regardless of prior state — manually editing/pruning workspaces.json has no lasting effect since the file is rewritten within the same second the process starts.

Expected behavior

  • kimi should not automatically watch every ancestor directory of cwd. At most it should watch the resolved project workspace (cwd, or the git repo root), not $HOME or /.
  • Watching should stop well before filesystem root — an ancestor walk that reaches / for any project is almost certainly a bug, not intended behavior (no one wants "install a filesystem watcher on /" as a side effect of running a CLI in a subdirectory).
  • Failing that, at minimum: EMFILE from a background workspace watcher should degrade gracefully (log + disable that watcher) rather than crashing the whole process via an unhandled error event on FSWatcher.

What I tried that didn't help

  • Raising ulimit -n up to 200000 (near the OS's kern.maxfilesperproc hard ceiling of 245760) before launch — still crashes, consistent with the watched tree being far larger than the fd budget (home directory + full filesystem root).
  • Pruning ~/.kimi-code/workspaces.json down to only the active project — kimi re-adds the ancestor entries (home dir, parent dir, /) on the very next launch.
  • Checked kimi --help, kimi doctor, and ~/.kimi-code/config.toml for any flag/setting to disable workspace auto-registration, ancestor watching, or the "global search" indexer — found none.
  • Confirmed already on latest published version (0.36.1 per kimi --version and ~/.kimi-code/updates/latest.json).

Suggested fixes

  1. Stop walking ancestors past the resolved project/git root when registering workspaces.
  2. Never auto-register (or auto-watch) $HOME or / as a workspace.
  3. Wrap the background workspace FSWatcher in an error handler that disables that specific watcher instead of letting the error event go unhandled and crash the process.
  4. Expose a config flag / CLI option to disable the ancestor workspace registration and/or the "global search" watcher entirely for users who don't want it.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing workspace auto-registration from the launch path and the watcher setup that writes ~/.kimi-code/workspaces.json. Reproduce with kimi -p "reply with just OK" from a nested project directory, then verify that ancestor roots such as $HOME and / are not watched and that an EMFILE watcher error does not terminate the process.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, typescript
Domain
cli, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.