A long-lived `serve --mcp` process opens `.codegraph/codegraph.db` and holds
the fd for its whole life. If `.codegraph/` is removed and recreated AT THE
SAME PATH while it runs — `git worktree remove <p>` + re-add, or `rm -rf
.codegraph` + `codegraph init` — the held fd points at the now-unlinked inode
and can never see the new index. The server serves the pre-removal snapshot
(renamed/removed symbols still "live", new ones missing); `codegraph sync`
can't refresh it and the CLI (a fresh process) diverges. Only a restart fixed
it — and because the daemon registry is keyed by path, a same-path recreate
routes new clients straight back to the same stale daemon, so the fix has to
self-heal inside the running process.
- DatabaseConnection records the DB file's (dev, ino) at open and exposes
isReplacedOnDisk() — a different inode now at the same path. POSIX-gated:
Windows can't unlink an open file and its st_ino is unreliable, so it never
fires there.
- CodeGraph.reopenIfReplaced() opens the live file first, then swaps the
connection + query layers IN PLACE (via the new wireLayers() helper), so
every holder of the instance (the daemon's default project, cached
projectPath connections) heals without a restart. Closing the dead handle
also frees the leaked db/-wal/-shm fds pinning the unlinked inode.
- ToolHandler.getCodeGraph calls it (freshen) before serving — one stat() per
call, a no-op unless the inode actually changed, never throws into a tool.
Tests cover isReplacedOnDisk (unchanged / replaced / absent / Windows-gated)
and an end-to-end reopen that heals a held instance after a same-path recreate
(asserts the pre-heal staleness too). Validated on macOS with a dist probe of
the raw instance and the MCP serving path; full suite green.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
e43ac82cdf