Problem
When multiple MCP servers run on the same computer (e.g., from different IDEs or terminals), conflicts occur during concurrent index modifications. The MCP-servers may index the same codebase in parallel, overwrite each other’s snapshots, create duplicates in the vector DB, and cause desynchronization between the Merkle tree and Milvus. This leads to data corruption, excessive load, and unpredictable system behavior.

Possible solution
Implement a Leader Election pattern via file locks (flock). On startup, each MCP-server tries to acquire an exclusive lock on ~/.context/leader.lock. The one that succeeds becomes the leader and is allowed to modify the index (indexing, sync, cleanup). The others become followers - read/search only. Every N seconds, followers check whether the lock is available to automatically recover if the leader crashes.

Key advantages: simplicity and reliability. The OS guarantees a single leader and automatically releases the lock if the process dies. All critical writes are performed atomically via temporary files and rename. Current operation tracking uses in-memory process state rather than files, which prevents stale on-disk markers from crashed servers.

what do you think about this?