Standalone dashboard (--ui=true) dies silently within seconds, no stderr output

[JoseVallejoMorey]

Version

codebase-memory-mcp 0.8.1

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

The standalone UI dashboard (--ui=true --port=<port>) exits silently within
seconds of launch, with no error printed to stderr. This happens specifically
when another process (a long-lived Claude Code stdio MCP session) already has
the same project's graph.db open. I confirmed it's not a port-conflict/TIME_WAIT
issue by reproducing it on a never-before-used port (29749) with identical
results.

I expected the standalone dashboard to either work correctly alongside an active
stdio session on the same project, or — if concurrent access to graph.db isn't
supported — to fail with a clear error message explaining why, instead of dying
silently with no diagnostic output.

Reproduction

1. Code being indexed: Not code-content-dependent — this appears to be pure
   process/lock contention, not related to file content. Our repro used a
   private ~1650-node / ~5700-edge Python/FastAPI repo, but any indexed
   project (including a minimal public one) should reproduce it identically.

2. Exact steps:
   a. Index any project via an MCP stdio session (e.g. Claude Code):
   "Index this project" → calls index_repository.
   b. Leave that session open and connected — its stdio server process keeps
   graph.db open.
   c. In a separate terminal, launch the standalone dashboard against the
   SAME indexed project:
   codebase-memory-mcp.exe --ui=true --port=9749
   d. Process exits on its own within 1-20 seconds. No stderr output.
   e. Reproduced identically on a never-before-used port (29749), ruling out
   TIME_WAIT / port reuse as the cause.

3. Output vs expected:
   Actual: silent exit, nothing printed to stderr, nothing retrievable via
   GET /api/logs (server is already dead by the time you'd query it).
   Expected: either successful concurrent access to graph.db from both
   processes, or a clear error on stderr (e.g. "graph.db locked by another
   process") instead of a silent, undiagnosable exit.

Logs

level=info msg=mem.init budget_mb=8131 total_ram_mb=16263
(nothing else printed before the process exits — no warning, no error, no
signal info; this is the entirety of stderr output captured before the
silent exit)

Diagnostics trajectory (memory / performance / leak issues)

Not collected — this is a crash-on-startup rather than a memory/performance
issue, so we didn't capture this initially. Happy to reproduce with
CBM_DIAGNOSTICS=1 if it would help triage.

Project scale (if relevant)

~1651 nodes / ~5715 edges, graph.db ≈ 7.1 MB (7,471,104 bytes).

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.