UI binary crashes (clean exit) while rendering 3D graph

[sandeepshekhawat]

Bug Report

Description

The ui variant binary crashes with a clean exit (no error message, no stack trace)
while the 3D graph is rendering in the browser. The process simply terminates silently.

Environment

• Version: 0.7.0
• OS: macOS 26.2 (Build 25C56)
• Arch: darwin arm64
• RAM: 16 GB
• Variant: ui (installed via install.sh --ui)

Steps to Reproduce

1. Install the UI variant: curl -fsSL .../install.sh | bash -s -- --ui
2. Run: tail -f /dev/null | codebase-memory-mcp (to keep stdin open)
3. Open http://localhost:9749
4. Wait for 3D graph to render

Observed Behavior

Process exits cleanly mid-render. Logs only show:
level=info msg=mem.init budget_mb=8192 total_ram_mb=16384

No crash dump, no error, no signal info.

Expected Behavior

Graph renders without crashing the process.

Additional Notes

• The MCP stdio tools (search_graph, trace_path, etc.) work fine
• Crash is reproducible every time the graph attempts to render
• KeepAlive in LaunchAgent does not restart the process after this crash

[DeusData]

Thanks for the report. A clean exit (no signal, no stack) mid-render points to a deliberate exit path rather than a SIGSEGV — the UI server runs alongside the MCP stdio loop, so the whole process goes down if either side exits. I can't reproduce it without a bit more:

1. Exit code — capture it right after it dies (e.g. …; echo "exit=$?").
2. Verbose stderr up to the exit — paste the last ~30 lines (the only line so far is mem.init).
3. Graph size — the nodes/edges from the index_repository response for the project you're viewing (you're on 16 GB / budget 8192 MB, so I want to rule out a size/budget exit).
4. Does it reproduce with a small project (a few files), or only on a large graph?
5. After the exit, do the MCP stdio tools still respond, or is the whole process gone?

A repro project (or just its approximate node/edge count) would help most.

[DeusData]

One material change since my last comment: v0.8.1 replaced the UI's entire HTTP transport layer with a new implementation. Worth retesting the 3D graph view there — could you give v0.8.1 a try?

If it still exits cleanly mid-render, the details from above (terminal output at exit, the tail of the --ui log) would localize whether it's the render path or the server side going down.

[kNoAPP]

Also seeing this issue appear. I have an extremely large codebase that's multilingual (GO, Dart, TypeScript, etc.). The knowledge graph contains 50,634 nodes and 261,567 edges. The UI, when I try to load the graph, crashes the whole utility.

alden@Mac ~ % codebase-memory-mcp --ui=true --port=9749
level=info msg=mem.init budget_mb=18432 total_ram_mb=36864
zsh: killed     codebase-memory-mcp --ui=true --port=9749

[xiaokyo]

One material change since my last comment: v0.8.1 replaced the UI's entire HTTP transport layer with a new implementation. Worth retesting the 3D graph view there — could you give v0.8.1 a try?

If it still exits cleanly mid-render, the details from above (terminal output at exit, the tail of the --ui log) would localize whether it's the render path or the server side going down.

v0.8.1 is not working too
macbook pro m1pro's chrome

[tanglinhong]

I also came across the problem，and the output in terminal was:

codebase-memory-mcp --ui=true --port=9749
level=info msg=mem.init budget_mb=18432 total_ram_mb=36864
zsh: killed codebase-memory-mcp --ui=true --port=9749

my codebase has 76008 nodes and 271597 edges, the version of codebase-memory-mcp is 0.8.1

[DeusData]

Thanks to everyone who chimed in — the pattern is clear: --ui=true on graphs above
roughly 50 k nodes reliably hits killed on macOS Apple Silicon. We're working on a
fix and need to distinguish OOM (SIGKILL from the OS) from an internal assert.

Instructions for your coding agent:

# 1. Capture the exit signal precisely
codebase-memory-mcp --ui=true --port=9749 &
CBM_PID=$!
# Open the UI in the browser, wait for it to die, then:
wait $CBM_PID
STATUS=$?
echo "exit_status=$STATUS"

# 2. While it's running, sample RSS until it dies (run in a second terminal)
while pgrep -x codebase-memory-mcp > /dev/null; do
  ps -o pid,rss,vsz -p "$(pgrep codebase-memory-mcp)" 2>/dev/null
  sleep 2
done
echo "process gone"

# 3. Check for a macOS crash report (written even for OOM kills)
ls -lt ~/Library/Logs/DiagnosticReports/ 2>/dev/null | \
  grep -i codebase | head -5
# If any exist, paste the first 50 lines of the most recent .ips file

# 4. Confirm graph size
codebase-memory-mcp cli list_projects 2>/dev/null | grep -E 'nodes|edges'

# 5. System info
sw_vers
sysctl -n hw.memsize | awk '{printf "%.0f GB\n", $1/1073741824}'

The macOS crash report (.ips in ~/Library/Logs/DiagnosticReports/) is the most
valuable artifact — it contains the termination reason and, for OOM kills, the memory
footprint at kill time.

Thank you for your patience while we get this fixed!

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.