Codebase-memory opening a huge number of file descriptors

[jonnyom]

Debugged with Claude to find what was causing it

⏺ Bash(lsof 2>/dev/null | awk '{print $1}' | sort | uniq -c | sort -rn | head -15)
  ⎿  161770 codebase-
     11044 node
     1420 com.apple
     1154 plugin-co
      742 corespotl
      721 zen
      680 Browser
      640 Notion
      631 python3.1
      615 Amazon
      456 Dia
      451 zed
      450 Linear
      426 Raycast
      425 Music

                                                                                                                                                                                                                                                                                               11:12 AM claude-opus-4-6
⏺ There's your culprit: codebase- (codebase-memory-mcp) has 161,770 open files — that's 88% of your system's total. Your system limit is 184,320 and you have 194,389 open files trying to be used.

Not sure exactly how this has happened, but I do constantly see claude trying to re-index projects that were already indexed. Wouldn't surprise me if that was related

[DeusData]

Interesting. Can you maybe share what OS/hardware you use? Will dig into this. This should not happen

[DeusData]

We investigated the C codebase thoroughly and cannot find a file descriptor leak — every fopen/fclose, popen/pclose, and sqlite3_open/sqlite3_close pair is balanced across all code paths.

A few questions to narrow this down:

1. Which version are you running? (codebase-memory-mcp --version) — if it's v0.4.x (Go), the C rewrite in v0.5.0+ has a completely different architecture that avoids many of the Go runtime's FD accumulation patterns.

2. How many MCP server processes are running? (pgrep -c codebase-memory-mcp) — Zed may spawn multiple instances that each open stores + git subprocesses. The lsof count is per-system, not per-process.

3. Is auto-index or the watcher running? The watcher polls git via system() / popen() on every cycle. If an MCP server process isn't cleanly terminated, the watcher thread keeps spawning git subprocesses indefinitely.

If you're on v0.4.x, updating to v0.5.3+ would be the first thing to try. If you're already on v0.5.x and can reproduce, lsof -p <pid> for a single process would tell us exactly what's being held open.