MoonshotAI / MoonshotAI/kimi-code
Startup crash: EMFILE: too many open files, watch — kimi auto-registers and watches every ancestor directory up to /
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 explicitulimit -n 200000before launch — same crashlaunchctl 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
cdinto any project directory nested a couple of levels under$HOME(e.g.~/Development/some-project).- 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). - Observe the process crash with an unhandled
FSWatchererrorevent.
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 ownnode_modules){"root":"/","name":"", ...}(filesystem root — workspace idwd_workspace_e3b0c44298fc, which is the first 12 hex chars ofsha256(""), 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$HOMEor/. - 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
errorevent onFSWatcher.
What I tried that didn't help
- Raising
ulimit -nup to 200000 (near the OS'skern.maxfilesperprochard 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.jsondown 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.tomlfor 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.1perkimi --versionand~/.kimi-code/updates/latest.json).
Suggested fixes
- Stop walking ancestors past the resolved project/git root when registering workspaces.
- Never auto-register (or auto-watch)
$HOMEor/as a workspace. - Wrap the background workspace
FSWatcherin an error handler that disables that specific watcher instead of letting theerrorevent go unhandled and crash the process. - 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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