Bug

The server does not guard against multiple instances opening the same SQLite database simultaneously. When more than one server process is running (e.g. after an upgrade that left the old process alive, or after a user registers the server both as a plugin and as a separate MCP server via npx), all instances write concurrently to the WAL file.

SQLite WAL auto-checkpoint requires no active readers to truncate. With multiple servers constantly reading and writing, the checkpoint window never opens. Every write from every instance just appends to the WAL indefinitely.

Reproduction

1. Start two instances of the context-mode server pointing at the same data directory
2. Call any write tool (e.g. ctx_index) from both instances repeatedly
3. Observe the WAL file size growing without bound
4. Observe all queries progressively slowing until they hang

Real-world result

On a system with 5 concurrent instances (2 from upgrades not cleaning up old processes, 3 from a user registering the server as both plugin and npx MCP server), the WAL grew to 238MB. Every ctx_search call hung indefinitely — the server appeared completely unresponsive, with no error returned.

Fix options

Either:

Option A — Exclusive SQLite lock on startup:

db.pragma('locking_mode = EXCLUSIVE');

This causes the second instance to fail immediately with a clear error rather than silently competing.

Option B — PID lockfile:
Write a .lock file in the data directory on startup containing the current PID. On startup, check if the lockfile exists and if that PID is still alive. If so, refuse to start with a clear error message.

Option B is more user-friendly as it surfaces a descriptive error.

Expected behaviour

Starting a second server instance against an already-open database should fail immediately with a clear error: "Another context-mode server is already running (PID: XXXX). Stop it before starting a new instance."

Environment

• Platform: Windows 11
• Claude Code plugin
• context-mode v1.0.127
• SQLite WAL mode