Repository navigation
Standalone dashboard (--ui=true) dies silently within seconds, no stderr output #909
Description
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
-
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. -
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. -
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.
Activity
LoveDoLove commentedon Jul 7, 2026
Just go web browser open the localhost:port
sniperrenren commentedon Jul 7, 2026
it`s mine:
codebase-memory-mcp --ui=true --port=9749
level=info msg=mem.init budget_mb=8192 total_ram_mb=16384
[1] 1965 killed codebase-memory-mcp --ui=true --port=9749
putout nothing
DeusData commentedon Jul 7, 2026
Thanks for the clear standalone UI repro. Triage: high-priority Windows/UI stability bug under #394/#396.
If concurrent stdio and UI access to the same graph cannot be supported in this path, the binary must fail with an actionable local diagnostic rather than exiting silently. Review should also check whether the project-locking work now in flight covers this case.
DeusData commentedon Jul 11, 2026
v0.9.0 shipped a substantial rework of the standalone UI server path (process lifecycle, port handling, error surfacing — the Windows '--ui=true never listens' report #707 was confirmed fixed by its reporter on v0.9.0). There's a fair chance the silent-death-within-seconds you hit is the same underlying class. Could you retest with v0.9.0? If it still dies, please attach the last lines of stderr/terminal plus your OS and how you launched it — with v0.9.0 the process should now either serve or fail with an actionable diagnostic, so a silent exit would be exactly the evidence we need.
github-actions commentedon Jul 11, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.github-actions commentedon Aug 1, 2026
This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked
stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.DeusData commentedon Sep 19, 2026
Thank you for the original report. We have not verified that the standalone Windows UI exit described here is fixed, so I am keeping this open rather than treating the elapsed time as resolution.
Could you retest on v0.11.0 and let us know whether the UI still exits while the MCP client is running? Please include the exact launch command, whether you use the UI release variant, and any sanitized stderr/daemon log around the exit. Do not include repository content or credentials. The release is available at https://github.com/DeusData/codebase-memory-mcp/releases/tag/v0.11.0. Thank you for taking another look.
github-actions commentedon Oct 11, 2026
This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked
stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.DeusData commentedon Oct 19, 2026
Thank you again for reporting the silent UI exit. Checking back on the requested retest: does it still happen on your current CBM version while the MCP client is running? The exact launch command and a short redacted error/log excerpt would help if it does. There is no newly verified fix to claim from this sweep.
DeusData commentedon Oct 25, 2026
Thank you again for the report. If you have already retested the silent dashboard exit, please share the exact version and outcome; the earlier log request remains sufficient.