Release request: publish the macOS watcher fd exhaustion fix

[ZHOUKAILIAN]

The current npm latest (@colbymchenry/codegraph@0.9.9) can still exhaust the macOS system-wide file table when codegraph serve --mcp starts on a large project. main appears to already contain the fix in c9559d9 / #650, but that change is not yet in the published npm package.

Observed on macOS 14.8.5 / Apple Silicon with the npm-installed 0.9.9 package:

• System proxy/network apps started failing; Feishu/Lark and WeChat showed no network signal.
• macOS reported Too many open files in system (os error 23) for new processes.
• sysctl kern.maxfiles kern.num_files showed kern.num_files: 122426 with kern.maxfiles: 122880.
• lsof showed two codegraph serve --mcp processes holding most of the system file table:
  • one process with about 61,434 open fds, 61,419 of them REG
  • another process with about 54,508 open fds, 54,495 of them REG
• After terminating those codegraph serve --mcp processes, kern.num_files dropped back to about 6,381 and other apps recovered.

The installed 0.9.9 dist still references the older chokidar watcher path, while repository main has the native fs.watch hybrid watcher and the CHANGELOG entry describing the macOS per-file fd exhaustion fix.

Could you publish a new release containing #650 / c9559d9? This is a high-impact operational issue because it can break unrelated applications system-wide on macOS once the file table is exhausted.

Workaround for affected users until a release is published: stop stale codegraph serve --mcp processes and install/build from main, or disable the daemon/watcher temporarily.

[Zombieliu]

Another affected user — macOS 15.7.8 (24G806), Apple M1 Max, 64 GB. +1 to publishing the fix. Observed on 0.9.6; per this issue the same chokidar path is still shipped in 0.9.9.

A single codegraph serve --mcp daemon on a large game-asset repo reached 245,750 open REG fds — pinned exactly at kern.maxfilesperproc (245760) — pushing kern.num_files to 255,478 / 491,520. macOS then returned ENFILE to unrelated processes within the same second:

• Claude Desktop (Electron) renderer killed by SIGTRAP; Google Chrome browser process abort() with SeatbeltExecClient: pipe failed: Too many open files in system; WeChat GPU helper + several macOS daemons (replayd, mediaanalysisd, etc.) all crashed simultaneously.
• lsof of the daemon: 245750 REG, only a handful of PIPE/DIR/KQUEUE — i.e. the leak is per-file REG descriptors. The same files were held open ~500× each.
• .codegraph/daemon.log had grown to 1.27 GB, ~1/3 of lines being EMFILE: too many open files, watch '.../original-map/WemadeMir2/Tiles/####.png'.

The held-open files are git-tracked binary assets (public/original-ui/**, original-map/**/*.png) — so they can't be excluded via .gitignore — and are amplified across multiple git worktrees and timestamped asset-snapshot dirs.

Killing the daemon dropped kern.num_files 255,478 → 9,730 instantly and all apps recovered. serve --mcp --no-watch mitigates it. Looking forward to #650 / c9559d9 landing in a release — thanks for the quick root-cause!